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

  • 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.


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.
  • 1
    Tested right now on Windows 7 Explorer: Create 100 characters file in 200 characters directory, get The file name(s) would be too long for the destination folder. Feb 10 '13 at 5:21
  • Adobe AIR is also subject to the ~255 characters limit with File operations even on Windows 7.
    – Maurycy
    Feb 18 '13 at 19:08
  • @Nicolas Raoul: do you want to say your sync tool is using Explorer to actually copy files? In this case, you're probably doing it wrong and may consider a better alternative (Interop for .NET Framework applications) which is not only faster, but also is not subject to terrible length limitation. Feb 18 '13 at 19:49
  • @MainMa: My app downloads files with System.IO.File.OpenWrite and System.IO.Stream.Write, I thought it was the recommend way. The alternative you mention sounds interesting, but googling "Interop for .NET Framework" does not show any result that seems relevant... could you please detail the idea? Thanks a lot! By the way, our code is open, in any case: github.com/nicolas-raoul/CmisSync/issues/107 Feb 19 '13 at 3:06
  • 1
    @NicolasRaoul: Here's the source code and the corresponding unit tests. Sorry for the inconvenience. Jun 4 '14 at 2:12

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.

  • Thanks for the tip, unfortunately the files need to be 100% usable by other applications, so I guess the \\?\ trick should be avoided in this case. Feb 13 '13 at 3:26

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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.