1910527 - Long file paths on Windows (ws2:longPathAware)

Status: UNCONFIRMED

(Core :: Widget: Win32, enhancement, P5)

Description

[monkeyiq]

Attachment: Small test web page to try to load a directory of files.

Steps to reproduce:

Using Firefox 128.0.3 64bit on Windows 11 23H2 22631.3958. I found that the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled was set to 1 already. This should allow paths for a file longer than 260 bytes.

When uploading deep file trees with FileSender long paths do not appear in the upload dialog. I have also created a cut down web page asking for a directory and dumping the resulting files to the web console (2kb index.html attached) with the same results.

One test is to make a nested directory structure with 64 byte directory names and try to add that whole directory to the browser. The script below can create this structure which I have in nested-zip.tar here:

$ tar tvf /tmp/nested-zip.tar
drwxrwx--- ben/ben 0 2024-07-30 09:00 nested-zip/
drwxrwx--- ben/ben 0 2024-07-30 09:00 nested-zip/0123456789_123456789_123456789_123456789_123456789_123456789_64/
drwxrwx--- ben/ben 0 2024-07-30 09:00 nested-zip/0123456789_123456789_123456789_123456789_123456789_123456789_64/0123456789_123456789_123456789_123456789_123456789_123456789_64/
drwxrwx--- ben/ben 0 2024-07-30 09:00 nested-zip/0123456789_123456789_123456789_123456789_123456789_123456789_64/0123456789_123456789_123456789_123456789_123456789_123456789_64/0123456789_123456789_123456789_123456789_123456789_123456789_64/
drwxrwx--- ben/ben 0 2024-07-30 09:00 nested-zip/0123456789_123456789_123456789_123456789_123456789_123456789_64/0123456789_123456789_123456789_123456789_123456789_123456789_64/0123456789_123456789_123456789_123456789_123456789_123456789_64/0123456789_123456789_123456789_123456789_123456789_123456789_64/
...
This relates to https://github.com/filesender/filesender/issues/1957

A sample directory tree can be made with the following. On the current 128 version it will list only three files. If the application manifest is updated to include ws2:longPathAware it should hopefully show all 12 files.

...bash code below...

dname="0123456789_123456789_123456789_123456789_123456789_123456789_64"

for if in seq 1 12;
do
mkdir $dname
cd $dname
echo "nesting at $if" >> file.txt
done

Actual results:

File paths that are longer than around the 256 bytes are silently ignored. This can happen when the directory is traversed recursively and there are a number of subdirectories. Single directories need to be about 211 bytes long which is rarer but not impossible. This also depends on the file name in the directory to the path length of 260 characters total.

Expected results:

All the nested files and directories should have been presented to the web form. It seems that the longPathAware key must be in the application manifest for windows to allow longer paths to be offered.

Comment 1

[monkeyiq]

Information about long paths and windows https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

Comment 2

[Francesco Lodolo [:flod]]

Moving to a Windows related component, please move to another product/component if this is not relevant.

Comment 3

[Ray Kraesig [:rkraesig]]

Unfortunately, there's a lot of code in Firefox, all over the place, that assumes that a Windows path can't be longer than MAX_PATH. While we're generally pretty good about checking whether that's actually true, all that means is that if we flip that bit in the manifest, we're slightly more likely to fail with an error than we are to crash. "Correct, useful behavior" isn't on the list of plausible outcomes without a lot more work.

Furthermore, it appears that very few other applications have any support for this — even the Windows shell itself doesn't appear to properly handle long file names, as we've found in (e.g.) bug 1906455. LongPathsEnabled also does not appear to be enabled by default in Windows 11, or at least wasn't, as recently as a year ago — my Win11 laptop has the relevant registry key, but set to 0.

To quote a Chromium dev from https://issues.chromium.org/issues/40119902, who put it better than I would:

[W]e would need to see clear signaling from Windows that LongPathsEnabled is the way going forward and that changes to the Windows Shell support this direction.

Unlike that Chromium issue, though, I don't think it's appropriate for us to close this as WONTFIX. We're quite happy to consider patches from external contributors intended to improve Firefox's handling of overlong paths. (Readers who are interested in contributing such patches should probably file a new bug referencing this one and describing the scope of their intended changes.)

P5/S4, at least until such time as Microsoft provides the "clear signaling" in question.