onyxogen

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.

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. 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.

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 :-)