arynhard Posted May 3, 2014 Report Share Posted May 3, 2014 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? Quote Link to comment Share on other sites More sharing options...
aaronliao Posted May 5, 2014 Report Share Posted May 5, 2014 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? Could you tell me a bit more about your configuration? OS, version of Sync on host/peers, etc? aaron Quote Link to comment Share on other sites More sharing options...
arynhard Posted May 7, 2014 Author Report Share Posted May 7, 2014 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. Quote Link to comment Share on other sites More sharing options...
arynhard Posted May 7, 2014 Author Report Share Posted May 7, 2014 I am getting the following when looking at systemctl status...sync btsync[359]: LoadTorrent: file....exists, but failed to get mtime 36Not quite sure that the file it is referencing is the one causing the issue because it is the encrypted name. Quote Link to comment Share on other sites More sharing options...
RomanZ Posted May 12, 2014 Report Share Posted May 12, 2014 @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. Quote Link to comment Share on other sites More sharing options...
arynhard Posted May 13, 2014 Author Report Share Posted May 13, 2014 @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? Quote Link to comment Share on other sites More sharing options...
RomanZ Posted May 29, 2014 Report Share Posted May 29, 2014 @arynhard Actually I don's see other alternatives. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.