Allow long path names

[J. Rathlev]

It seems that FileZilla server cannot handle path names exceeding the maximum path length of 260 character Windows sets by default.
Using the Unicode versions of Windows API functions and the UNC file extensions would permit longer file pathes.
More infos: Windows SDK - File names

[Igor]

I've just added a related (as I believe) bug ​here.

[Matthew Harris]

Now that Node has become more popular it seems this issue needs some attention. Some of the tickets go back a decade.

I haven't looked at the FileZilla code but as far as I know its just a case of swapping out the existing file write method with a different one that will support the longer filenames.

Windows itself still has patchy support - you can look at the folders but not many Windows components will support opening, moving or deleting them. I normally do this through a VM but that doesn't mean that this shouldn't be resolved for FileZilla.

As it stands I cannot sync my site if it uses node packages and I would guess that web developers must be the major users of FTP these days.

[Tim Kosse]

Not going to happen. There are too many Windows API functions which simply cannot handle such filenames.

For example the WIN32_FIND_DATA structure used by the FindFirstFile and FindNextFile functions, both used by FileZilla Server, are hard-coded to MAX_PATH, they cannot be used for longer filenames

Furthermore, not even Explorer, Windows' very own file manager, can handle such filenames.

[J. Rathlev]

This is not entirely true:

1. FindFirstFile and FindNextFile do support UNC paths, see:

​https://msdn.microsoft.com/en-us/library/windows/desktop/aa364418%28v=vs.85%29.aspx[[BR]]

2. The WIN32_FIND_DATA structure has a limit to MAX_PATH, but only for the filename not for the whole path.
   

3. Windows Explorer is based on the shell functions (not on the API functions) which do not support long pathnames.
   

From my own programming experiences I know that long pathnames are supported by the API functions. Besides there are file managers like TotalCommander that also support long pathnames.

[Tim Kosse]

Windows itself needs to endorse this feature first.

[J. Rathlev]

For my opinion all current Windows versions support this feature:

1. As I just tested, the Explorer in Windows 7 can look into directories with long pathnames (>260). It seems that "cAlternateFileName" in WIN32_FIND_DATA is used as workaround,
2. As I know, all Unicode versions of the API functions needed for file handling support UNC absolute paths (e.g. functions to create or delete files, to read or write, to modify attributes or timestamps and FindFirstFile too). It is just required to prepend "
   ?\". For example, "
   ?\D:\very long path". Everything is described in the Windows SDK:

​https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath

So it would be very desirable to have this feature also in FileZilla.

[Igor]

Personally, I strongly agree with jrathlev - old API is limited and obsolete. All today's apps must use unicode, as well as "UNC paths". I'm also surprised, that there's so little interest in this feature (from the users community).

I even had an intention to "fork" filezilla server's code and fix these issues, at least for my own use. This does not seem like a large project... However, as usual, I don't have much free time, currently.. so, I've just postponed this idea... Maybe after a few months...

[Tim Kosse]

All today's apps must use "UNC paths". I'm also surprised, that there's so little interest in this feature (from the users community).

If "all today's apps" must support overlong paths, why don't the reference apps from Microsoft support it? Let me answer this one: There simply is no such requirement.

It is just required to prepend "
?\"

No, it isn't. The prefix disables processing of the path. All the safety checks done by the Windows API are bypassed and need to be re-implemented in the program using the prefix. Which checking needs to be performed varies based on the underlying filesystem. There are all sorts of shenanigans one can do with unchecked paths.

[Igor]

Replying to codesquid:

All the safety checks done by the Windows API are bypassed and need to be re-implemented in the program using the prefix. Which checking needs to be performed varies based on the underlying filesystem. There are all sorts of shenanigans one can do with unchecked paths.

Well... OK, I do understand your concern. Even though I do not know much about such attacks. Neither I know whether all (or some) of those issues could be avoided by, say, passing each file name through "GetFullPathName" (AFAIK, it aims to do just that – “parse” or “normalize” the path string. And it works OK for long paths – just add “\\?\” after this “normalization”.). Could you please provide an example, where this approach fails?

I agree this might be a good reason to disable such paths in GUI, if this could be considered as a "vulnerability". But... why not leave an ability to set such a path directly in “FileZilla Server.xml”? (Or add some (hidden?) “allow_unsecure_long_paths” setting, to be absolutely sure, that user actually knows what he is doing)

If "all today's apps" must support overlong paths, why don't the reference apps from Microsoft support it? Let me answer this one: There simply is no such requirement

Yep, you're right. There's no such formal requirement. I was only trying to say, that, IMHO, not supporting these paths is as ridiculous, as not supporting Unicode.

[J. Rathlev]

This issue should be picked up again. The Microsoft documentation concerning extended paths using the prefix \\?\ has been revised:
​https://msdn.microsoft.com/en-us/library/aa365247.aspx

Cit.: Using an extended path will only disable all string parsing which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory, or double dots to represent the parent directory.

There seems nothing to be that affects any safety issues. On Windows 10 there is no limitation to MAX_PATH characters when opening a file and many applications (e.g. LibreOffice) do support this. Why should this not be possible in FileZilla server?

[Igor]

In #11229 Tim Kosse asked if Windows Explorer is able to handle long paths, saying that "It's a necessary prerequisite".

Now, Windows 10 v1903 is perfectly able to do that out-of-the box.
And that effectively means that all up-to-date versions of Windows are able to do that.

So, maybe now you could kindly consider implementing this feature?

[Andre]

It seems that LongPath support isn't functioning properly on Windows 11.
One workaround is to use the
?\C:\<ftp folder path> format in the user configuration.
However, this method doesn't appear to be compatible with the latest version of FileZilla Server.
I was able to get it working with version 0.9.96.2.