Disappointed Cat

UNC, long paths on Windows

Recommended Posts

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 by Lightning

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 post-20346-0-64858000-1367139462.gif to raise.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now