#6193 reopened Bug report (rejected)
Allow long path names — at Version 4
Reported by: | J. Rathlev | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | FileZilla Server |
Keywords: | Cc: | i3v@… | |
Component version: | Operating system type: | Windows | |
Operating system version: | Windows |
Description (last modified by )
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
Change History (4)
comment:1 by , 14 years ago
Operating system type: | → Windows |
---|
comment:2 by , 12 years ago
Cc: | added |
---|
comment:3 by , 9 years ago
Type: | Feature request → Bug report |
---|
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.
comment:4 by , 9 years ago
Description: | modified (diff) |
---|---|
Resolution: | → rejected |
Status: | new → closed |
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.
I've just added a related (as I believe) bug here.