FileZilla can't handle long path names

[njyoder]

Because you can't create a single ticket for both FileZilla client and server, I have created a duplicate one for each.

Both FileZilla client & server can't handle long path names. They are programmed to use the MAX_PATH constant when dealing with files, which only allows a full path/filename of up to 260 characters. This is only a limitation of FAT32 and doesn't exist on NTFS. This results in errors making it impossible to transfer files whose path names are too long.

For NTFS, there are ways of working around this limitation, allowing for path names of 32,768 characters (specified by GetVolumeInformation (lpMaximumComponentLength)). Utilizing UNC (unicode) filenames allows you to get around this.

For reference, see this MSDN page:

​http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/naming_a_file.asp

There is also a discussion on this forum page:

​http://forum.sysinternals.com/printer_friendly_posts.asp?TID=5676

[Igor]

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

[Tim Kosse]

Using UNC paths is dangerous. It disables syntax checking and allows creating files and directories that are inaccessible in most programs, including Explorer.

As long the native Windows tools cannot handle long paths, no such support will be implemented in FileZilla Server either.

[Igor]

That's a pity (that this ticket got closed)...

AFAIK, there's no other simple mechanism for accessing these files. In many cases users do need long paths. A number of related bugs (see references in the ticket, referenced in my comment above)

I'm not sure how exactly it could be dangerous... IMHO, most file browsers do support UNC, including windows explorer (its UNC support is being improved gradually, as far as I've noticed).