Long paths support

  • Hello

    The latest version is not able to open files with paths bigger than I suppose MAX_PATH (260 chars ) under Windows

    Could you please fix that?

  • @The-gods-almighty-will

    If someone reads this later, they will not know what the “latest version” you are referring to is. Please be explicit, e.g. “This does not work under Notepad++ 7.8, but it did work under version x.x”. Better yet, include your Debug Info from Notepad++'s ? menu; it’s your easiest option.

    I find that with 7.8 (32-bit) I can open a file on C: drive with a total path length of 258 characters, but a file with a total path length of 259+ characters (non-unicode chars, I guess I should say) FAILS to open (quietly, no error message, just no load). Note that the same failure occurs under 7.7.1 (32-bit and 64-bit) so this doesn’t appear to be a “latest version” problem…

  • It depends on what you mean by “not able to open”. Mine opens it just fine… it just uses the windows short-name:

    My npp 7.8 64-bit, with ? > Debug Info =

    Notepad++ v7.8   (64-bit)
    Build time : Oct  7 2019 - 00:55:55
    Path : C:\usr\local\apps\npp-historic\npp.7.8.bin.x64\notepad++.exe
    Admin mode : OFF
    Local Conf mode : ON
    OS Name : Windows 10 Enterprise (64-bit) 
    OS Version : 1903
    OS Build : 18362.356
    Plugins : mimeTools.dll NppConverter.dll NppExport.dll 


    The ** ? > Debug Info > Copy debug info into clipboard** is quite useful for telling us what version you have (and is much less ambiguous than “the latest version”, when we have no proof that you’ve been informed that a new version just came out a few days ago, but hasn’t yet gone to automatic-update, so even though “Update Notepad++” doesn’t show a new version doesn’t mean you have the most recent. You might, but we cannot know; and providing actual version numbers, including bitness and the other stuff from Debug Info, will help us help you.)
    Screenshots (which you can now just paste into the forum post editor) also help show what’s going on.

    For example, in my screenshots, I’ve got a folder named C:\usr\local\apps\npp-historic\npp.7.8.bin.x64\AbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghijAbcdefghij, which contains a file name 123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456789x123456.txt, which contain 247 + 200 (plus the one separator between), for a total of 448 characters in the path. When Notepad++ tries to open that, it uses the windows short-name of C:\usr\local\apps\NPP-HI~1\NPP78B~1.X64\ABCDEF~1\123456~1.TXT, which it opens just fine.

    When I tried to create my long filename, I used windows explorer RClick > New > Text File, and pasted in the 304 character name (123456789x * 30 + .txt), and Windows truncated it to just be 200 characters total for the filename. (There may have been about 60 characters in the path where I created it)

  • @PeterJones said in Long paths support:

    Mine opens it just fine…

    Ooooh, interesting (given that it doesn’t for me)!

    Notepad++ v7.8 (32-bit)
    Build time : Oct 7 2019 - 00:58:16
    Path : C:…\npp.7.8.bin\notepad++.exe
    Admin mode : OFF
    Local Conf mode : ON
    OS Name : Windows 10 Enterprise (64-bit)
    OS Version : 1709
    OS Build : 16299.1387
    Plugins : ColumnTools.dll Explorer.dll LocationNavigate.dll MarkdownViewerPlusPlus.dll mimeTools.dll NppConverter.dll NppExec.dll NppExport.dll PythonScript.dll

  • @Alan-Kilborn said in Long paths support:

    (given that it doesn’t for me)!

    That might be 32-vs-64 bits. Or it may be because no individual node (file or directory) violated the 260 character limit.

  • @PeterJones said in Long paths support:

    That might be 32-vs-64 bits

    Nope. That same file opened in the 32-bit version as well

    Notepad++ v7.8   (32-bit)
    Build time : Oct  7 2019 - 00:58:16
    Path : C:\usr\local\apps\npp-historic\npp.7.8.bin\notepad++.exe
    Admin mode : OFF
    Local Conf mode : ON
    OS Name : Windows 10 Enterprise (64-bit) 
    OS Version : 1903
    OS Build : 18362.356
    Plugins : mimeTools.dll NppConverter.dll NppExport.dll

  • @PeterJones @Alan-Kilborn

    different handling depending on used dialog, see here.

  • @Ekopalypse said in Long paths support:

    different handling depending on used dialog

    But mine doesn’t show the problem, whichever version of dialog I use. For my 64bit vs 32bit experiments above, I was using drag-and-drop. Then I used 32-bit, with OLD vs NEW File > Open dialog settings, and so far, all my experiments have been able to open the filename I specified.

    If @Alan-Kilborn and/or @The-gods-almighty-will could show an example pathname that fails, so that others can test, that would be good.

  • @PeterJones said in Long paths support:

    If @Alan-Kilborn could show an example pathname that fails…


    This one (total path length of 258) works:


    This one (total path length of 259) fails quietly to load when drag-n-dropped or File > Open’d with N++7.8 32 bits:


    Note that I use XYPlorer as my file manager, which makes it easy to see the filename length and the complete path length (it also colors paths >= 260 in RED; the green is just indicating “recently-created”):


    Of course I wrote some cheezy Python (not Pythonscript) for quick-file-generation for testing this:

    # -*- coding: utf-8 -*-
    import os
    def T__main():
        cwd = os.getcwd()
        if not cwd.endswith(os.sep): cwd += os.sep
        temp = 'len_test_XXX_Y.txt'
        accum = 'a'
        for l in range(1, 1000):
            really_temp = temp.replace('Y', accum)
            really_temp = cwd + really_temp
            count_str = '{0:03}'.format(len(really_temp))
            really_temp = really_temp.replace('XXX', count_str)
            with open(really_temp, 'w') as f: f.write(count_str + '\n')
            if len(really_temp) > 265: break
            accum += 'a'

  • Hmm…

    I don’t have a standalone python on this machine (lost it when my work computer died and was replaced last month), and don’t have the time to do a new install right now.

    If I run your python code using PythonScript, it only creates up to 259 (after that, it’s not allowed to open the filename, giving errno 2: “no such file”, which is what the OS says when you try to use an invalid name). I tried to do the equivalent in perl, perl also propagated the OS errno 2 beyond 259.

    When I tried to load len_test_258_a.....txt in 7.8-32b, it loaded, and when I tried 259, it failed (didn’t even try shortname). The same happened in 7.7.1-64b, so it’s not a regression.

    I know that Win10 Anniversary Edition (1607) is supposed to allow for names longer than 259…
    Ahh, on my work computer, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem has the value LongPathsEnabled = 0, and I am not allowed to change it (don’t have full admin privileges, especially in some sections of the registry). That’s what’s preventing me from creating files that long. As far as Notepad++ opening them or not, without that LongPathsEnabled being set to 1, there’s very little chance of it working. If it is enabled in the OS, then there is a chance. According to this site (which is where I find the registry entry),

    This new setting won’t necessarily work with every application out there, but it will work with most. Specifically, any modern applications should be fine, as should all 64-bit applications. Older 32-bit applications need to be manifested in order to work, which really just means that the developer has indicated in the application’s manifest file that the application supports longer paths. Most popular 32-bit apps should experience no problem. Still, you don’t risk anything by trying the setting out. If an application doesn’t work, the only thing that will happen is that it won’t be able to open or save files that are saved in places where the full path exceeds 260 characters.

    So, if it doesn’t work, even with the registry value set, there might be something that Don could do in a future revision.

  • @PeterJones

    As you’ve probably guessed, on my system LongPathsEnabled is, well, enabled:


  • @Alan-Kilborn ,

    Have you tried with a 64-bit portable on your machine, or just your normal 32-bit? I’d be curious whether the “as should all 64-bit applications” is true, or whether that “manifest file” setting needs to be made for 64-bit as well as 32-bit.

  • @PeterJones said in Long paths support:

    Have you tried with a 64-bit portable on your machine

    Yes. Same result whether N++ was 32-bit or 64-bit.

  • Even this all is quite old but I found the thread because I ran into rthe same “Long Path/FileName” situation with Notepad++ 7.8.6 (64-Bit).

    And I guess the solution is to check following regedit:


    NtfsDisable8dot3NameCreation - Set to 1 or 0

    Some SSD “optimization” programs change this to 0 to reduce some load to SSD.

    If this is 0 for you change it to 1.

    But note that Win10 uses then the the old short-names again which have an influence on generel file handling preformance.

    No reboot required but you need to copy the corresponding file back and force that Win10 creates the (hidden) 8.3 file name (for this file) in background.

    After that you can open it as 8.3 file name as @PeterJones already has shown.

  • @Dj-Maniac
    Correction :-)

    Some SSD “optimization” programs change this to 1 to reduce some load to SSD.

    If this is 1 for you change it to 0 (which is the standard)

  • Try “LongPathTool program” that is best solution.

  • Banned

    This post is deleted!

Log in to reply