Best practice to sync long paths to filesystems where path length is limited?

Question

I wrote a sync tool to synchronize folders/files from Alfresco to Windows.
PROBLEM:

• In Alfresco, /files/can/have/very/very/very/long/filepaths/like/this.txt
• The Windows API prevents me from creating a path with more than 260 characters.

In addition to telling the user there is a problem, what is the best practice in such a case?

1. Shorten the file's name?
2. Skip the file?
3. Create a sort of "folder's carriage return", a special folder from which the path can continue?
4. Something else?

Files need to be 100% usable by other applications. If necessary directory names can be modified, I can keep a mapping.

Answer 1

The problem you mention doesn't exist, since the limit you specified in your question is wrong.

• Until Vista, Explorer was limited to 248 characters.
• .NET Framework File is limited to 260 characters (MAX_PATH).
• The real maximum path for Windows itself is approx. 32,767 characters.

I have no idea where have you found the mention of 255 characters.

Now, if you're syncing files to an operating system which doesn't allow 32,767 characters-length paths (like very old versions of Windows), then:

• Skip the file,
• Inform the user that there is an issue with the length of the given files. Do it only at the end of the process, not file by file. There is nothing more annoying that being disturbed dozens of times during a process because there are dozens of files that cannot be synced.
• Don't shorten the file name. You have a good chance to cause more trouble with collisions.

Answer 2

See the MSDN article on maximum path length limitations for some additional ideas.

You can try some of the following depending on what is available to you:

• Attempt to use "extended-length paths" starting with \\?\ but be aware of the limitations such as no relative path names.
• Map a longer path to a drive using subst to artificially shorten the path.

If you absolutely are unable to sync the file, then the best practice would be to skip the file and note all skipped files in some sort of error report, or quit early, noting that you are unable to complete the sync as desired.

Answer 3

If you really do need to shrink the path down (dubious - see other answers) what about some kind of hash? If you need to preserve the bi-directional mapping mapping of file names you could store that somewhere else, such as a database. Not super convenient but if you must shorten the file names it's just not going to be as convenient as you would like.

Answer 4

This is just a rehash of existing answers by MainMa and Jay Lindquist.

• Use the underlying Windows API which supports the maximum path length of 32,767.
• Create the document with the full path, but also create a symbolic link somewhere in a folder at a shorter depth:
  • C:\exported files\Links to documents with path names too long\shortened_name.doc

Then, a list of such documents and their full path location can be reported at the end of the operation.

Note about the .NET framework: this blog article at MSDN more accurately describes the recommended practices with regard to compatibility with other applications.

Answer 5

On MacOS / ios path length is limited to 1023 utf8 bytes, and every path component is limited to 255 utf8 bytes. Going anywhere near this limit is madness, but it is a limit and an attempt to synchronise a folder could go beyond it.

With that kind of limit I wouldn’t care, the synchronisation just fails. (Obviously telling the user or the calling software etc).

I would be tempted to do the same for a 256 character path limit. You might try to determine the maximum path length before you start copying, and either tell the user that external data cannot be copied, or that it can’t be copied to a folder with say more than 12 characters.

Note that with a low limit there’s a good chance that renaming a folder could make files inaccessible with a full path, totally independent of your software.