#31 Cannot backup long file names / directories

[Anonymous]

Create Synchronicity supports file systems such as NTFS that allow for much larger than 260 (generally MAX_PATH) characters, but fails to back them up.

To reproduce:
1) Create a folder with > 260 characters in the full path on a NTFS partition (left) and backup to NTFS partition (right).
2) Attempt to back up
Note: Windows 7 x64

Results:
Error: mscorlib
Error detail: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters

Expected:
To succeed

I'm not sure what libraries are being used, but ensure that nothing is using MAX_PATH / related nonsense. I see that this is in VB, so I'm sure it's not being used directly. MAX_PATH (260) is so 1990's!

[NuSkooler]

FYI, here is a implementation allowing for long file name / paths & some information regarding why the current class does not allow for such:
http://bcl.codeplex.com/wikipage?title=Long%20Path&referringTitle=Home

[Clément Pit-Claudel]

Ahem. Windows 7 is so 1990's =)

See http://synchronicity.sourceforge.net/faq.html for a quick answer;

See http://msdn.microsoft.com/en-us/library/aa365247.aspx (or http://stackoverflow.com/questions/265769/maximum-filename-length-in-ntfs-xp-and-vista) for more info: the 260 chars limit is still in use, and windows just won't let you create anything longer. The message results of a system call, not of doing an an actual check in the code.

In other words: If you check the stacktrace of the problem, you'll see that the error is raised by a call to a system copy function.

Sorry, for that, but you'll have to wait a little more for more-than-260-chars-long filenames ;)

I did check the article you submitted, but I believe they put it much better than I do: http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx . I mean, implementing the solution that you suggest would mean that users could not even review the backup in explorer, because explorer doesn't handle such paths: would you trust a backup that a few programs only, using vaguely documented syntactic tricks, can handle? I wouldn't.

Yet I'm quite frequently faced with this problem; sadly the Microsoft response is: make your filenames shorter.

Thanks,
CFP.

[NuSkooler]

I think you may be misinterpreting what some of these articles are stating. Windows (at the very least Vista+) support long file names properly via most APIs and certainly in Windows Explorer. The data set I'm using right now has been backing up properly with long file names since Vista from and to the same drive (using a different backup program, of course). Sure, various APIs such as LoadLibrary() do not support it, but this is not a backup issue. If one has a directory with long file names, this API would fail; If they backed up said directory of course the API would continue to fail if used from the new backed up path. The files would be accessible in Windows Explorer, however.

I think saying "Windows is broken" here is a mistake. Possibly pre-Vista, sure (though I think this works in XP as well). Other backup programs do this just fine, Windows Explorer supports it, and I've yet to come across something that can't read these files from their long path (remember: It's the total path length in question, not a file name or one node in the directory that is > 250 chars)

[Clément Pit-Claudel]

I'l just quoting the articles you submitted:

"First about security, the \?\ prefix not only enables long paths; it causes the path to be passed to the file system with minimal modification by the Windows APIs. A consequence is that \?\ turns off file name normalization performed by Windows APIs, including removing trailing spaces, expanding ‘.’ and ‘..’, converting relative paths into full paths, and so on. The existence of FileIOPermissions in .NET means that we absolutely have to work with normalized paths, or risk exposing a security threat. So we knew that if we wanted to use the \?\ prefix as part of the long path solution, we’d need the ability to normalize these paths as expected."
That means higher risks, more potentially bogus code, and so on.

"Let's start with the simplest example – deleting a file. Recall that Explorer won't let you delete long path files, so you'll need this to clean up the files you create in the subsequent section."
That's not really what I call "supporting it""

"Either way, suppose .NET lets you create paths up to 32K in length. Now you have a new problem: you have a file that, most likely, no other app on your system can use. It would have to support the \?\ syntax. Furthermore, many .NET APIs won’t even be able to work with this file: recall from Part 1 that this syntax only works with the Win32 file-related APIs, but not for general Win32 functions that accept paths (e.g. LoadLibrary)."

If your system crashes, and you want to restore something, you're not going to do it with Create Synchronicity. If you then discover that your files are not accessible from the command line, you're going to be extremely crossed.

But if you really want Create Synchronicity to act this way, please go and modify the "TranslatePath" in SettingsHandling.vb function to prefix paths with "\?\", it shouldn't take more than 30s =) I won't do it, because of the high probability that users may be confused by this.

As an extra reading, I suggest that you read http://www.codinghorror.com/blog/2006/11/filesystem-paths-how-long-is-too-long.html =)

And as a side note,since I originally believed what you wrote without challenging it:
Quoting you:
"Windows (at the very least Vista+) support long file names properly via most APIs and certainly in Windows Explorer. "
This is not true. Did you try it? I did on Windows 7. It didn't work, at all. If it works for you, please do post a screenshot here. The reasons I mentioned in my previous post still hold therefore.
" I've yet to come across something that can't read these files from their long path"
Well, any .net program using the system IO functions.

Once again though, it's about adding at worse 10 chars to the code. Do if you want =)

[sam locas]

Well, you can use Long Path Tool for such issues, it works good.

[ana gray]

I had this problem before and I now use Long Path Tool and it is so easy to use and very helpful

[Michel Rouzic]

It's disappointing that this problem isn't dealt with because the files that Create Synchronicity refuses to copy are easily copied to their destination using Windows Explorer. That means I have to find a new backup tool that does things correctly.