UFTT for windows can't handle paths longer than 260 characters

[GoogleCodeExporter]

I'm creating this issue to discuss and document the MAX_PATH limitation on 
windows.

What steps will reproduce the problem?
On a windows machine, either:
- Upload a share containing a file with abolute path > 260 characters
- Download a share resulting in a file with abolute path > 260 characters

Now the upload/download will abort with an error.

For windows NT+ it is possible to work around this: 
http://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath

We could implement this in UFTT, but i'm not 100% sure if we should. Such files 
with an absolute path > 260 characters won't be accessible by most 
applications. On windows XP even explorer cannot handle them so there is not 
even an easy method to delete such files.

Should we implement this? Should it be a runtime option? Should it default to 
on or off? Should the option be 'hidden' (advanced settings only)?
Also, can explorer handle such files on windows vista/7?

Original issue reported on code.google.com by simon.sasburg@gmail.com on 22 Oct 2011 at 7:34

[GoogleCodeExporter]

Original comment by simon.sasburg@gmail.com on 22 Oct 2011 at 7:35

• Changed title: UFTT for windows can't handle paths longer than 260 characters

[GoogleCodeExporter]

Testing shows the windows 7 explorer automatically switches to the shortform 
notation for long filenames (like Progra~1 and such) in order to avoid the 
MAX_PATH limit. But when the shortform of a path is larger than MAX_PATH 
explorer will be unable to view it.

Original comment by simon.sasburg@gmail.com on 7 Nov 2011 at 11:39

[GoogleCodeExporter]

Implementing features that even window's own file-manager can not handle does 
not make sense to me. If we transfer such a file (or set of files), but the 
user is still unable to do anything with them we could just as well not have 
transferred them in the first place.
Therefore I feel we should focus on other areas of UFTT first. 

I propose we close this issue as WONTFIX for now, it can be re-opened if/when 
there is a genuine need to create and transfer paths with greater lengths. 
Until then a clear, unambiguous error describing the problem and possible 
work-arounds (optionally including a link to this issue) should suffice. 

ps.
If such a warning still needs to be implemented please change the status of 
this issue to Assigned or similar instead.

Original comment by daniel.g...@gmail.com on 15 Dec 2011 at 1:30

• Changed state: Accepted