Long paths support

Ekopalypse

different handling depending on used dialog, see here.

PeterJones

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!