Reboots And Android Sleep Cause Old To Overwrite Current?

[JimmyTheSaint]

We discussed the problem of old overwriting new in this thread:

 

http://forum.bittorrent.com/topic/24744-overwritten-by-older-version-of-file/

 

but I'm now noticing a specific pattern to the problem that I think deserves its own thread for consideration. Since disabling Android sleep a week ago, an old version hasn't clobbered a current version on any of my clients except under one very specific circumstance: machine reboot. I've never seen the problem associated with any of my Windows laptops, but in the past week I've seen it subsequent to:

 

1) one of my Linux NAS's underoing some sort of automatic restart at its remote location, I assume due to a power outage followed by its automatically-restart-after-power-outage feature.

 

2) a Note 2 manual full reboot, after I noticed that it had been disconnected from my home LAN for a couple of days and that I couldn't switch on its WiFi until I rebooted.

 

3) an S4 full reboot after it experienced one of its very, very rare crashes.

 

Since each is a case where the client lost the network in an ungraceful way, I presume that's what's been causing this intermittent overwriting anomaly all along. I do plenty of reboots with my Windows laptops, soft reboots with my Android devices, and an occasional Linux reboot, and those orderly shutdowns have never led to the old-overwrites-new anomaly. I don't think every single crash reproduces the problem, but my sense is that it's the vast majority. So the question for the devs is what prevents BitTorrent Sync from failing gracefully even when the machine doesn't. I imagine sometimes when the operating system breaks, it's going to break BTS, but perhaps they can find ways to improve the OS/BTS failure ratio. Meaning that maybe BTS can be made more likely to fail gracefully when the OS totally barfs.

 

Maybe that's much easier said than done, but because the problem has virtually disappeared when I've turned off Android sleep, I'm worried that there are issues specific to Android sleep that cause the same BTS anomaly as an ungraceful shutdown. I've experienced a significant number of occasions where the BTS app became unresponsive after trying to switch to it while sleep was enabled. I actually rarely need to deal with files from within the app itself, except on the occasions when I can plainly see that suddenly hours had gone by without a sync, despite my 30-minute sleep period. When BTS app apparently seizes, I do give it a lot of time to come back, then when it doesn't, I kill it with a task killer. During my one week experiment, however, the app has worked absolutely perfectly--remember, my only S4 problem during the week was when the OS itself crashed. And by "perfect," I mean switching networks willy-nilly (WiFi and 3G), renaming files and folders and then renaming them again 2 seconds later when I changed my mind, moving files and then moving them again quickly, creating and then deleting or moving a few seconds later--these are needed working file operations that frequently led to glitches for me when using Android sleep. In fact, it had gotten to the point where I was doing things with files outside of synced locations and then moving them in when finished, which is really not how you want to work.

 

I have to infer, then, that something about sleep doesn't get along with Android. I suspect the system comes along eventually and does something horrible to apps that it thinks have become inactive. Simple solution: I've stopped using Android sleep--after all those battery statistics I posted cheerleading for the feature! It's really quite a luxury to have instant sync all the time and no sync glitches except when OS's crash. 20% per hour battery consumption is viable on my S4 because the spare battery I now carry is so cheap and light and convenient to pop in there when needed. I've been saying for years now that user-replaceable battery and extra micro-SD card are dealbreakers for me, and Samsung has declared their commitment to these two features for their flagship phones. Although such high battery consumption is unnacceptable to a lot of people, I would think within a few years battery capacity and hardware efficiency will bring the % per hour usage down low enough that you don't care how many mA per hour the BitTorrent Sync app is using. But even though we're not there yet, I think I'm going to have to permanently quit the Android sleep feature, or else lose sleep worrying over tracking and searching clobbered files.

[JimmyTheSaint]

OK, I just had the same pattern happen again. I left one of my Windows laptops sleeping for about a week. It resumed without error, and then BitTorrent Sync proceeded to sync without error. When it was done, that machine had added back some files that had been moved, renamed, or deleted days before by the other clients. I presume that if those files had been modified and left in place, then that Windows laptop would have overwritten new with old. I haven't actually tested for overwriting, but improperly "resurrecting" is verified. It only seems to happen when a machine syncs after a long time off line (days or more) or after a machine crash, which rarely happens--but 4-5 power outages per year at one location are guaranteed, even if unpredictable. I've never seen the problem when rebooting an already up-to-date client. There seems to be something about being off line for a certain length of time (or crashing) that confuses sync somehow. Any hypotheses, suggestions, and possible diagnostics are welcome.

 

Otherwise, the only workaround seems to be to never sleep a syncing device for too long--whatever "too long" means. That can actually work for me because three of my Windows laptops have SSD's and they're either on 24/7 or frequently re-awakened; my Androids sync 24/7; and my Linux NAS's do have spinning hard drives that never rest, but that's what their server HD's are designed for. I only have one backup Windows box left with a spinning HD that I rarely use, so I'd like to let it sleep. It's also viable to plan to never buy another laptop with non-solid state storage. But it might be nice to be able to use the Android BTS app's auto-sleep function sometimes.

[JimmyTheSaint]

It happened again. I shut down one of my Linux NAS's in order to install a UPS. So that's an orderly shutdown followed by a normal reboot. Two days later, I realized I'd forgotten to manually restart the btsync process, which you have to do with the Linux client. Experienced now, I monitored history after the process came up, and sure enough, the NAS's old versions overwrote a whole bunch of files that I'd updated in the last two days. It's really quite a tedious job of bookkeeping to track down and restore everything, and the longer you fail to realize that a client rebooted, the worse it's going to be. And this was my worst episode yet, as I'd done a lot of different work in the two intervening days. I have to conclude that I've definitely lost stuff in the past that I don't even know about, before I learned to methodically track this glitch. It's particularly pernicious because these devices can sometimes automatically reboot themselves without your realizing it, such as after a Windows update or after a power outage. The occasional erroneous reboot happens with Android, too.

 

Isn't this a rather serious bug? Can anyone else test on a Windows or Linux client by shutting it down and then rebooting 24 or more hours later and after there have been a variety of file changes?