Read-Only Encrypted Key Bug

[onyxogen]

A file that gets stored on a remote computer that has a read-only encrypted (!) bug gets a new (encrypted) name. For example mytext.txt will become A5MQKBUZKCQSWMMLXMFY4F4LWN2LYBEF3AL53TKSQ6GSHYMQ5W55YRSUN45PHI5WTT

.

This leads to a foreseeable problem: Windows can only handle 255 characters in filename. So especially once you reach a certain folder depth the sync failes because the destination file path gets too long. You can't sync anything that exceeds this value, it will simply fail.

 

It's not a bug, I know. But it makes the feature quite useless for me.

But as it is a beta feature, I'm confident that you find an other solution :-)

[RomanZ]

onyxogen,

 

Thanks for reporting. We'll check how can it be adjusted to consume lesser space from max_path and still make sure that filename is unique.

 

For now I can advise host encrypted-read-only folders as close as possible to the tree top and use short names for the directories themselves, like E:\ecnr1, E:\encr2, etc. This will safe the rest of MAX_PATH for the filename.

[Firon]

That's only 66 characters. Just don't put it 8 directories down and you'll be fine.

This is already a limitation with many other things.

That being said, it is possible to make Sync actually write these files (uT does already in some cases!) with the \\?\ prefix in paths, but that'd have to be handled internally.

[AlwaySyncd.com]

Is this a problem only if the RO encrypted share is running on a windows system?

 

If you have a RW share running on a Windows system and the sister RO encrypted share on linux does it cause the same problem?

[RomanZ]

onyxogen,

 

Actually Windows allows around 32k for the full path and filename. BTSync is using the API which does not limit file operations to MAX_PATH variable (which is only 260 bytes), while Windows Explorer uses older API and might have issues displaying folders and files, which has summary length more than MAX_PATH.

 

However, there are bunch of file managers over Internet, which are able to browse long paths with no issues. 

Could you please share what is your usage scenario which makes long paths an issue?

 

AlwaySyncd.com,

Linux has a limitation of 4k for path and file name. Terminal should not have any issues, also it looks like shells (Gnome, KDE, etc.) also have no issues.

[onyxogen]

onyxogen,

 

Actually Windows allows around 32k for the full path and filename. BTSync is using the API which does not limit file operations to MAX_PATH variable (which is only 260 bytes), while Windows Explorer uses older API and might have issues displaying folders and files, which has summary length more than MAX_PATH.

 

However, there are bunch of file managers over Internet, which are able to browse long paths with no issues. 

Could you please share what is your usage scenario which makes long paths an issue?

 

AlwaySyncd.com,

Linux has a limitation of 4k for path and file name. Terminal should not have any issues, also it looks like shells (Gnome, KDE, etc.) also have no issues.

 

I don't know if I made it clear, I don't need to browse the encrypted files (why would I? They are encrypted :-) ) So a file manager that allows me to browse long paths does not help.

 

Let me explaing the bug again.

Say, you sync from RW-folder to a RO-encrypted folder:

 

Normally you'll get something like this:

c:\myshare\test.txt -> c:\myencryptedshare\AE77IBTBM4PNEWVKIZDCWPMIKLATZRLEUAYY5ZCLCUSXQBSYZLVVM2MDMXYDY7EBBE

 

But:

c:\myshare\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\TestSubFolder\text.txt  (let's assume it's long enough..., > 255!)

 

-> you only get an error on the system with the c:\myencryptedshare  in the log with an event that says that file transmission failed. The file never gets transmitted.

 

Try it (Windows 7) yourself.

I hope that this helps to track down the bug. Maybe the same think happens (for a standard sync RW -> RW) if you sync from linux with extraordinary folder depth to windows with limited folder depth, but I did not verify that.

That's only 66 characters. Just don't put it 8 directories down and you'll be fine.

This is already a limitation with many other things.

That being said, it is possible to make Sync actually write these files (uT does already in some cases!) with the \\?\ prefix in paths, but that'd have to be handled internally.

 

Well, you are right. It's a limitation that stems from the different underlying file systems and I certainly don't expect that syncing different OS/file systems works without problems (though some do I think)

I only expect that syncing from one OS the same OS works in every case, and this rule is broken due to the lengthy file renaming BTSync does for "encrypted" syncing.

Edited March 12, 2014 by onyxogen

[RomanZ]

onyxogen,

 

Sorry, but i'm really missing the point where bug is. I did a couple of tests as you recommend:

 

Test #1.

WinXP bears a role of Encrypted-RO. Windows 8.1 as RW node, which shares the file.

File is stored in deep folder: C:\users\test\desktop\SyncEnc2\SubFolderEncr\[subfolderEncr 25 more times]\lua.dll

SyncEnc2 is actually synced folder. Path is 100% longer than 260 characters. Windows Explorer complains about long path somewhere on folder level 15.

Sync is done successfully, XP gets encrypted file on the same level depth.

 

Test #2.

The same, but RW node was iMac. Also, no reproduction, all the folder path was synced with the file at the bottom.

 

And actually there should no be any issues by design, as on Windows BTSync is using a Unicode version of file API which is limited to ~32Kb file path length.

 

Could you please:

1. Advise if I correctly got the idea of your test. If yes - any issues / mistakes you see in my test (except I did not grab Win7, did not had one at hand)

2. Share your use case? Are you using some extremely-deep tree to store data?

3. Share the screenshot of the error you get. Who is producing this error?

[onyxogen]

 

 

Could you please:

1. Advise if I correctly got the idea of your test. If yes - any issues / mistakes you see in my test (except I did not grab Win7, did not had one at hand)

2. Share your use case? Are you using some extremely-deep tree to store data?

3. Share the screenshot of the error you get. Who is producing this error?

 

Thank you for trying to reproduce the problem. You got the idea of my test. I re-did the test today with Win8 <-> Win7 (both directions) and I could not reproduce the error. I don't know why! It's a shame that I did not copy the exact error message. For now it seems that my problem had a different cause. 

[RomanZ]

okay then. Don't hesitate to contact me if you encounter the error once more. Make a sceenshot, or even better - check what is the process displaying error.