[Sync Queue In A Frozen State With Encrypted Peer]

@arynhard,

 

What is your dir depth an the longest path on non-encrypted peer? Encrypted names are ~+30% longer, so it might happen that target FS does not accept such long paths.

@RomanZ,

 

The depth ranges from 6 to 7. Some of the names of the files are long. Very possibly could be that the FS (ext4) is not happy with the length. After looking at other filesystem types it seems 255 bytes is the max filename length we can get. Is there any other alternative other than renaming the files?

[Sync Queue In A Frozen State With Encrypted Peer]

I am getting the following when looking at systemctl status...

sync btsync[359]: LoadTorrent: file....exists, but failed to get mtime 36

Not quite sure that the file it is referencing is the one causing the issue because it is the encrypted name.

[Sync Queue In A Frozen State With Encrypted Peer]

I am running sync 1.3.94 on opensuse 13.1. I have sync 1.3.94 running on a OS X Mavericks with the read write secret. My opensuse server runs with the API key and  the encryption secret.

[Sync Queue In A Frozen State With Encrypted Peer]

After switching my secrets over to the encryption secret for my server, I cannot get a complete sync. 600+ files are stuck in the queue. If I remove the file that sync is stuck on, then it gets stuck on the next file in the queue. Is anyone else having issues with the encryption secrets?

[Remote Delete]

I would like to see a feature added that enables a user to send a command to a remote btsync client that clears all data on that device only, including the hidden Sync archive folder. This can be very useful in the case of a lost or stolen device.