Bug: Long pathname support under Windows 10 >= 1607
Status: UNCONFIRMED
Priority: --
Created: 2021-03-23 18:38:06+00:00
Resolved: 2021-03-24 04:54:19+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36

Steps to reproduce:

Hi,

Managing my emails under Windows is restricted because of the long pathname limitation (260). Windows 10 supports longer pathname with a registry modification since release 1607 (https://docs.microsoft.com/en-gb/windows/win32/fileio/naming-a-file#maximum-path-length-limitation).

Create a folder (or many folders one under the other) in the hierarchical folder tree for which the full pathname will go beyond the 260 character limitation.

Or

From the webmail client, create such a folder or label (GMail for example) that will go beyond the 260 character limitation when Thunderbird will try to synchronize it locally (remember that a part of the full pathname is already taken by the profile's location, like "C:\Users\UserName\AppData\Roaming\Thunderbird\Profiles\ProfileName\"

To be noted: most of my time is under Linux, which doesn't have this limitation about long pathname (well, there is one, but way longer than 260). But my work sometimes dictates me to use Windows. So I'm expecting a very similar experience between both OSes, and otherwise to be able to know when something is missing that I'm used to access under Linux.


Actual results:

A) Thunderbird doesn't uses the registry value for long pathname support when available (since Windows 10 version 1607).
B) Labels overflowing the 260 caracters limit are not listed in the folder tree.
C) No error is reported when creating such a folder while it will not appear in the hierarchical folder tree "after creation" (but the creation works properly, validated from the webmail client).

Details: If the long pathname support is not enabled (which is the default state), I can still create subfolders that will go over the 260 character pathname limitation (no error is thrown) from Thunderbird, but these subfolders will never show in the hierarchical folder tree. Also, if these subfolders (think about how GMail uses labels) are created through a webclient, they will be listed under "Subscribe..." and selectable as any other folder, but they will never appear in the hierarchical tree and no error will be thrown to the user to explain why they can't be retrieved locally.


Expected results:

A) Thunderbird should support long pathname since it was introduced under Windows 10 when the registry value is set to support longpath name.
B) If the support is not available, the "Subscribe..." window should identify problematic folders (maybe disable their selection or something similar) to remove any confusion or highlight them them in a particular way for the user to understand that they can't be sync locally.
C) If the support is not available, the creation of such a folder in the hierarchical folder tree should throw a warning to inform the user that while the folder / label was successfully created on the server side, it can't be created on the client side. Other option could be to throw an error and prevent the folder's creation from happening.

The question about long pathname support was raised before (https://support.mozilla.org/en-US/questions/1249512). While the answer explains why changing the Windows registry value doesn't seem to influence Thunderbird's ability to use longer pathname, it doesn't provide a solution to have long pathname support in Thunderbird.