Long paths support

The gods' almighty will

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?

Alan Kilborn

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…

PeterJones

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)

Alan Kilborn

@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

PeterJones

@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

@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

Ekopalypse

@PeterJones @Alan-Kilborn

different handling depending on used dialog, see here.

PeterJones

@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.

Alan Kilborn

@PeterJones said in Long paths support:

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

Sure.

This one (total path length of 258) works:

C:\XX\Utilities\npp.7.8.bin\plugins\Config\PythonScript\scripts\len_test_258_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.txt

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:

C:\XX\Utilities\npp.7.8.bin\plugins\Config\PythonScript\scripts\len_test_259_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.txt

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'

T__main()

PeterJones

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.

Alan Kilborn

@PeterJones

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

PeterJones

@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.

Alan Kilborn

@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.

Dj Maniac

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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

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.
https://support.microsoft.com/en-us/help/121007/how-to-disable-8-3-file-name-creation-on-ntfs-partitions

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

@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)

Juan Miller

Try “LongPathTool program” that is best solution.

Saritha Vuppala

This post is deleted!