nectar

Crashes have returned. Affecting 1.3.77 and 1.3.105.

I’m experiencing the same issue, suddenly. All with 1.3.94 on OS X 13C64 and 13C1021. Crashing thread always has a backtrace like: Thread 2 Crashed:0 com.googlecode.google-breakpad 0x003066ac google_breakpad::ExceptionHandler::UninstallHandler(bool) + 1901 com.googlecode.google-breakpad 0x00307098 google_breakpad::ExceptionHandler::WaitForMessage(void*) + 4262 libsystem_pthread.dylib 0x95b965fb _pthread_body + 1443 libsystem_pthread.dylib 0x95b96485 _pthread_start + 1304 libsystem_pthread.dylib 0x95b9bcf2 thread_start + 34 Full crash report: http://spo.onl/btsync.crash And I down-revved to 1.3.77 and now I am experiencing the same crash. So it appears to have to do with the content I’m syncing, and not the BTSync version. I’ve now removed all my sync folders from BitTorrent Sync, and started adding them back one by one. I’ve re-added about half of them, and all seems OK for the moment— the crashes have stopped. Unfortunately I am out of time this morning, but I’ll continue later in the day.

Asymmetric key lengths must be longer to match symmetric key security. See for example Table 2 in http://www.rsa.com/rsalabs/node.asp?id=2088 , and read the whole thing for a better understanding. 32 characters in base 32 = 32^32 = 2^160 That’s a potential key length of 160 bits, more than enough for AES-128.

Thanks for the pointer, GreatMarko. Of course, I unfortunately cannot seem to reproduce the issue so far.

Hi, I have two machines each with a collection of about 124GB of media. They were previously in sync using “rsync”. One machine (let’s call it the backup) was about a week out of date relative to the other machine (let’s call it the master). I set up Bittorrent Sync on the master, and let it completely index (this took a really long time). Then I used a one-time read-only key to set up the backup. Almost immediately I received a notification on the master that a file upload was completed. Checking history on the master, I saw: 4/25/13 2:39PM Finished syncing file 2013/2013-04/2013-04-21/JV20130421_24375_DSC_0447.xmp added by backup 4/25/13 2:39PM backup added file 2013/2013-04/2013-04-21/JV20130421_24375_DSC_0447.xmp Sure enough, the master now had a week out-of-date version of this file! I stopped the sync immediately. I double-checked the backup to ensure that it was read-only. In the “Advanced” tab for the folder on backup, it reads “Advanced Preferences are not available with read only secret”. This seems like a pretty serious flaw. How can I debug where things went wrong?

In addition to the already requested command line enhancements: Make the command line utilities available on OS X as well as Linux!