Crashes after first configuration (PathTooLongException) about ftpbox HOT 7 OPEN

While researching on this error a while back, when it was first reported, I found out that 260 characters is a length limitation for paths by the Windows API. From what I read there is a workaround, but it doesn't work in all cases and, given that .Net relies on the WinAPI a lot, this could cause even more problems.

For now, I suggest you just change your local path to a smaller one, that would fix everything...
I could get FTPbox to check the length in the setup forms and prevent the user from using one that exceeds the limit, so that at least there will be no crash...

from ftpbox.

Okay I checked my paths, and fixed the problem.

However, this was not one of the paths I use directly in a setup form, but rather a path encountered while traversing the directory tree.

from ftpbox.

Well this is the tricky part, the local sync folder might be less than 260 chars, but any subfolder might exceed the limit...
I'll see what I can do, I guess FTPbox should check each folder individually before calling any WinAPI methods...

from ftpbox.

Unfortunately, the problem of too long path names makes FTPbox completely unusable for me, especially when syncing an encFS-encrypted folder. I am not familiar with the source code, but there might be a possibility to fix those errors by adding a "?" prefix as mentioned here:

"To specify an extended-length path, use the "?" prefix. For example, "?\D:\very long path"." (http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx)

from ftpbox.

Workaround: Find the paths that are too long using http://pathlengthchecker.codeplex.com/ or by creating a textfile of all paths using the cmd command dir /s /b > out.txt and try to shorten them. For me, only one file had a path length greater than 260 chars.

from ftpbox.

.NET 4.6.2 now has support for long paths... on Windows 10, once you have jumped through a bunch of hoops. Still waiting for Microsoft to recognise that long paths are actually important to us .NET developers.

While we wait for that (without holding our breaths) there are alternatives.

My personal preference, which I have used in numerous programs over the last year or so, is Peter Richie's very excellent Pri.LongPath library (on NuGet). It replicates most of the relevant System.IO classes - Directory, DirectoryInfo, File, FileInfo, Path, etc - with calls to the Windows API methods that happily consume long paths.

In most cases it's simply a matter of changing the using at the top of your file, but you might need to alias some things from System.IO. These are the ones aliased in Pri.LongPath.FileInfo:

using FileAccess = System.IO.FileAccess;
using FileMode = System.IO.FileMode;
using FileStream = System.IO.FileStream;
using StreamWriter = System.IO.StreamWriter;
using FileShare = System.IO.FileShare;
using FileOptions = System.IO.FileOptions;
using StreamReader = System.IO.StreamReader;
using FileAttributes = System.IO.FileAttributes;

If you use any of those you need to either alias them or fully specify.

from ftpbox.

So I downloaded the project and replaced all the file operations with Pri.LongPath and it works... but my FTP server (FileZilla Server) can't handle those long paths. I don't have a decent Linux FTP server to test with at the moment, so I can't confirm that the code works.

The changes basically involved a blanket replace of using System.IO; with using Pri.LongPath; and adding aliases where required. I won't be doing a pull request until I can confirm actually working.

Incidentally, the FileSystemWatcher class handles the long paths without modification.

from ftpbox.