JimmyTheSaint

I had to reboot one of my Linux clients, and as usual I went a few days before I noticed that I hadn't manually restarted its btsync. That's always been a hassle because after that kind of delay, the restarted client has always clobbered a bunch of stuff. I upgraded to 1.2.91 and launched it, and this time it synced 100% cleanly, so that was a welcome fix.

emacs on Windows behaves like this, and it's quite nice to be able to save and have the saved version sync immediately. On the other hand, if I save an Excel or Word file, it won't sync until I close it. I can see that's a protection against clobbering changes, but I pretty much never want to operate that way. I must say I prefer emacs's behavior, and it warns you when you try to edit or save a file that's been altered on another client. But yes, you could mess up due to your own inattention and lose changes, and I've done that, too.

I don't know precisely what triggers the Android system app Media Storage to run, but I don't think individual apps can normally trigger it directly. While running BitTorrent Sync on my S4 to sync about 16GB/20k files, I've observed that Media Storage will run about once per day, for up to 2-3 hours and eat 20-30% of battery capacity. I've concluded that even a few file changes in conjunction with whatever files BTS updates as it keeps in sync are enough for the system to want to run Media Storage again. Since this frequency of battery drain is virtually useless for making my phone run better, I've disabled Media Storage, and I have no problems using my music player, PowerAmp. PowerAmp has a rescan function that I run manually when I add new stuff. In fact, sometimes it needs to be run manually even with Media Storage enabled so that I can get immediate access to any newly added stuff. So I'm suggesting to you to find a new media player that offers a working manual rescan for new media. Additionally, I don't miss whatever services Media Storage provides, but I still think it's too bad there's no way for the user to control it--and I've asked around. Unfortunately, it's required for certain minor things that most people can't live without, such as the stock Gallery app and ringtones. My phone never rings anymore, only vibrates, which I'm fine with, but a lot of people are married to their ringtones. Other audio notifications continue to work on their default settings, but can't be customized, and alas, many people are also married to their customized audio alerts. Since persistent, reliable 2-way sync on a lot of data without pause or sleep is high priority for me, I customize my phone around that, and it's been working great. But without devoting your whole phone experience to BTS, there may be a few changes you can make to get everything you need functional.

Android version?

The user guide only documents the advanced application settings (page 10), which you can insert at the end of the sync.conf file. But the standard settings aren't documented anywhere I can find, even if the function of some appears obvious.

Check the pinned thread above entitled "Latest <version number> build" and scroll down to the Android section. The direct download link to the Android apk is right there.

With RAID, all the drives reside at the same physical location, so if there's a physical disaster there, you're screwed. My NAS has two 3TB HD's set up as RAID 1, but when the amount of risk I was running became clear to me, I set up a second, identical NAS, cloned the first to the second as the OP describes, and moved it. In other words, I synced about 2TB, then moved the second NAS to another location far away. I had to turn off sync for all but my most active 15GB of sync folders because it's not practical to sync 2TB where I am unless they're on the same LAN. I've thought I could update the cloning by bringing the remote NAS back to the home LAN periodically and turning on sync for the 2TB portion. I'm too afraid to do that, though. I've reported sync glitches and data losses when rebooting Linux devices in other threads. I'm not confident in shutting a device down, moving it to the home LAN, and then syncing folders that haven't been in sync for several months. The 2TB sync would take a very long time, making it way too risky to end up having to track perhaps thousands of anomalies. I've thought I'm better off periodically bringing the second device back and re-cloning (syncing again from scratch). That kind of sucks, though, because not much of the 2TB actually changes (but too much to keep track of manually). And since cloning risks putting all my stuff in one physical location, I now want to find a third location and perhaps clone on a rotating basis. If anyone has a better idea to keep data reasonably safe using BTS exclusively, please post.

On Android, I never use the BitTorrent Sync app. I always use a file manager to browse and edit my files. When I save, BTS auto-magically detects the change and syncs it. Is that possible on iOS? I currently don't have any iOS devices to test, but will probably buy one again in the future.

Android 2.3 Gingerbread? ouch. RomanZ is right to worry about the excessive power consumption of Android's Media Storage process--it was running once or more per day on my phones, and didn't require reboots or storage mounts, which I guess is a feature of 4.x. I could manually kill the process, but it would always return soon enough until it was satisfied. I'm syncing 16GB/24k files on my phone, and my best guess is that BitTorrent Sync was causing enough file changes so that Media Storage would run and eat up 20-30% of my battery. My current solution: I've frozen Media Storage so that it never runs at all. I hardly miss it, but this solution won't suit everyone. Is it plausible that syncing a lot of stuff causes Media Storage to run more often?

Obvious question, but is everyone certain that the re-appearing file isn't open on some other sync peer? Apps such as Acrobat and Office apps will restore an open file that gets deleted via another client.

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?

That really sounds like a path/permissions issue. I assume you're the correct user (root or btsync) when you execute that command line. Perhaps create the conf file and directory manually so that you have the two directories ~btsync/bin and ~btsync/conf with the correct contents. Then cd to ~btsync and use a command line like mine: > bin/btsync --config conf/sync.conf

Sounds like the executable isn't in your path. cd to its directory and type "./btsync" and specify the conf file on the command line.

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.

If you kill the app, it will definitely stop syncing. You can always select the "Use Notification" option to keep the app's icon visible in the status bar as a reminder of the its status.

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.

If desperate, you can always try deleting the sync folder from inside the app, deleting the folder from your phone, and then creating a new, identical sync folder on your phone. You didn't say what version of the app you're running, but obviously it should be the current 1.2.14.

Yeah, then you have a lot of energy consumption. I posted stats in an earlier thread tracking how CPU usage increases with the amount of data being synced on my Linux NAS, but those CPU hogs were 100-2000GB.

What you're asking for is already here, to a degree. I edit .txt and .pdf files quite often, leave them open for days (accidentally or for convenience), save constantly, etc. They're updated and synced immediately, and everything works as expected without glitches. If I'm about to overwrite a newer version with an older version, my txt and pdf editors will warn me on Windows and Android. But I have to close Microsoft Word and Excel files to sync them because they get locked. So maybe this isn't a BitTorrent Sync feature or responsibility so much as it's a shortcoming/feature of the applications used to modify their files. I wonder if there are Office substitutes that don't lock .xlsx and .docx files.

Total number of files and GB you're syncing?

I still intermittently have this old-overwrites-new problem with Android. It's only with my S4, which is my only Android device to change WiFi networks and 3G location (my Note 2 never leaves home WiFi). I can't see a specific pattern, but it seems to only arise when the S4 and/or the laptop that tethers to its data plan have a slow 3G network connection, I guess due to the random fluctuations of my phone company. Changed files still occasionally get clobbered, maybe one file every 5-7 days. But that's often enough to be very unsettling so that I'm now constantly checking history on different machines, which makes using btsync much more of a chore. No telling if I've lost stuff because I didn't track my history closely enough. Once, I had an emacs save-file (starts with a '#') that I simply could not delete from any other client: the S4 would always add it back. I deleted it from the S4, no problem. But the rest of the time I don't mess around with the file in question because it's got real data--I just fix things quickly. As far as I can tell, all content has always been recoverable from the archive folder. But that presumes noticing the problem in your history, which could easily be missed for a file that's rarely changed. I currently suspect auto-sleep might have a connection (to this problem and to the losing sync issue), so I'll try going as long as I can without auto-sleep and see if the problem comes up. But sometimes I can go seven days or more without the problem, so there's no way to be conclusive.

I'm not clear what you mean by "let it go to sleep." By "sleep" I thought you meant Android's special power saving mode after the device has been turned off a while, and you'd need BetterBatteryStats to analyze that. Are you saying your screen never turns off? Obviously you could hit the power button, so I guess you're saying the screen never times out while BitTorrent Sync is running? That would be odd, unless you have an app that lets you choose apps that override the display timeout setting. Have you tried changing that display timeout setting while BitTorrent Sync is running?

In my case (refer to my signature), my DS213+ uses the Freescale QorlQ P1022 PPC CPU version. What kind of CPU does your NAS have?

How have you determined that the device never goes to sleep? You have to use an app like BetterBatteryStats to track the culprit with any kind of accuracy. Also see this thread.

I wonder if this is some kind of Android "feature"? For example, I use Android Tuner to back up my apps nightly. It offers an option to leave the screen on while backing up because that will make it run faster. I don't know how that works myself, but maybe this is also a question for an Android forum.