UNC, long paths on Windows

[Disappointed Cat]

We all know that the Win32 API is limited to 255 byte length path names.

Same mentality as "640K ought to be enough for anybody."

NTFS however does not have this limitation and for quite a while now windows supports UNC paths

by prefixing the path with '\\?\'. But there are also limitations: relative paths don't work with UNC.

My music library has a few really long paths which I can't/won't rename so I had to try this out with BTSync.

So I added my library this way, waited for the indexing for a lifetime and there, it works.

However Windows also creates magical shortened paths for paths that are too long, for example ASDASD~1. These get synced too, so I added filters to .SyncIgnore. This way the length limitation is gone, and programs can also handle them with the help of these short paths. But even though the peers synced successfully the apps always show there is still some GBs of data to transfer.

Is it safe to rely on BTSync working with UNC paths?

The only problem I encountered is the syncing of these shortened paths. In my case adding an exception for *~1 solves this but with some wierd paths or conflicting short names this fails.

Also there seems to be a bug when the are ignored files, the app shows on the devices tab that is has x GB to upload but it's actually synced. I readded the share in read-only mode and this problem goes away too.

Also read-only mode seems to require a lot less (like half) resources.

Edited May 20, 2013 by Lightning

[rdebath]

The windows API is limited to 255 UCS2 characters, or with Windows 7 it's limited to 255 (two byte) words encoded using UTF16.

Many Linux filesystems are limited to 255 Bytes normally encoded with UTF8 (BTSync seems to assume UTF8).

I haven't seen BTSync taking any notice of the "short" filenames in Windows; I suspect it's a bug if it does.

On windows relative paths only work in relation to the current directory; the current directory must begin with a mapped drive letter.

BTW: UNC means Universal/Uniform Naming Convention, not anything to do with unicode.

But in answer to your primary question; IMO UNC paths should work properly, if they don't raise a bug report.

[Disappointed Cat]

Many Linux filesystems are limited to 255 Bytes normally encoded with UTF8 (BTSync seems to assume UTF8).

I think 255 bytes per path level - at least on Debian based distros.

So you can't have longer filenames than that, but each directory can also have a long name.

Have you tried syncing a linux client and a windows client which has these "short" links or just windows to windows?

Because they do get synced between linux and windows but maybe another windows client would just say "Got it, chill".

BTW: UNC means Universal/Uniform Naming Convention, not anything to do with unicode.

You're right. The connection which I misunderstood is that Win API functions that have unicode versions support UNC. Link.

[rdebath]

I think 255 bytes per path level - at least on Debian based distros.

So you can't have longer filenames than that, but each directory can also have a long name.

You're right, It's each component of the path and it depends on the filesystem, 255 for ext3/4, around 140 for encfs on ext3 etc.

Have you tried syncing a linux client and a windows client which has these "short" links or just windows to windows?

Because they do get synced between linux and windows but maybe another windows client would just say "Got it, chill".

Hmm, most of the time I've only got one Windows machine and the rest are Linux ... Though I haven't tried a UNC path to the share ∴ your to raise.

[affinity]

In the windows world, I often use junctions to "enable" longer paths to work, ie a folder name is shortened and the shorter name brings the path within limits. The Windows tool is mklink, run it as administrator with no params to see how it works.

[Disappointed Cat]

That's pretty much useless in my case. The whole point here is not having to mess around with tens of thousands of files. Anyway, it wouldn't even work because first you have to download the files with the original paths which you can't do with windows explorer, neither with BTSync if you don't use UNC. Not mention I would end up with Foobar2000 monitoring things twice.

[vadimt]

We aware of this issue and it will be fixed in the next versions.

Thanks!

[Disappointed Cat]

Browsing the logs I noticed that all paths are now prepended with \\?\.

Is it safe to assume that UNC is now used by default?

[luckman212]

 

On 7/1/2013 at 10:26 AM, Disappointed Cat said:

I noticed that all paths are now prepended with \\?\.

Is it safe to assume that UNC is now used by default?

Did this ever get answered?

[Damien Brock]

I thing you have to try Long Path Tool