JimmyTheSaint

Nice guide. It's for those who have installed btsync via a community package. If you've manually installed btsync, then the btsync user you created will already appear in the DSM.

This user guide is only for those using the BitTorrent Sync package. If you've manually installed btsync, then the btsync user you created should already have a uid>1024.

I've created all my btsync directories as shared folders using Synology's File Station webui. So they're all of the form "/volume1/MyBtsyncDirectory." I vaguely remember running into the same problem you're having when I first started, but it's not in my notes. Since creating new File Station shared folders for each btsync directory has worked, I've just been doing that. I see that the permissions on File Station's shared folders are all 777, and apparently everything under them is 755 (directories) or 644 (files). I don't see any reason to mess with that because access is controlled via the Disk Station's "Users" utility.

Can you ssh into your NAS and recursively change permissions to the btsync user's directory to 755? or try 777, if necessary, just to see if it works?

I don't have a solution, but here's my experience using Keepass. I've been using Keepass all the time that I've been using BitTorrent Sync. Often, I leave Keepass open on one peer and open the same Keepass file on another peer, make changes, then save from that second peer, which intentionally clobbers the first peer's file when the changes are synced. When I return to the first peer, I simply quit Keepass so that it doesn't overwrite the second peer's changes. This has always worked as expected, and I've never had any sort of error or warning or lost data.

Which version of btsync? What's your CPU usage?

No, it was not pure idle: there were other peers (including 1.3.109 peers) online at the time. But the Linux box would stay at 25-35% even between sync periods. I reported this in the first 1.4 feedback thread, but I haven't tried any of the 1.4 updates on the Linux box I updated. On my other Linux NAS (identical hardware and system), I've done a clean install of 1.4.75 and haven't yet added any sync directories. It's been idling at 0% CPU, no problem. It's in a remote location that won't allow me to access the webui, so I still have to wait several more days before I can go there and test it to see if it plays well with my 1.3.109 peers. If it's OK, I'll try doing a clean install of 1.4 on my main Linux NAS and see how it goes.

Have you considered manually installing on Synology? I don't know if that will solve other issues, but at least it will enable more timely updates. I've put a manual installation guide for Synology online at: https://db.tt/99lZc7j8

Au contraire. The problem was solved with 1.3.109 on my Linux NAS's (~7%CPU), but 1.4 sent the CPU back up to 25-30%. I haven't tested the latest 1.4 yet.

I've gone through several recovery sessions in the past year. It's tedious, but I've always recovered everything using the history tab and the .SyncArchive folder. Does history reveal what happened? If the stuff's not in .SyncArchive, then I don't know what you can do. Stuff might get permanently lost once when you update to a new version, I'm not sure. I've learned to monitor history occasionally, even when I don't suspect any problems.

So I guess those are Linux NAS's? In that case, the 1.4 old-overwrites-new problem seems to be related to Linux or running Linux and Windows clients at the same time. I mean, we don't see other people reporting old-overwrites-new. As I mentioned, I'd like to try a clean re-install/re-sync on all devices at the same time, but I don't know when I'll have time for that.

I've always had that problem with my Linux boxes (I used to run two, but now it's one): any changes made while the Linux btsync process isn't running get clobbered as soon as I run it again. Since both of mine are NAS's, they're up 24/7, so I've only encountered the problem on occasion. But if one of my Linux boxes gets hit by a power failure that overwhelms its UPS, or if I don't ensure that everything else is idle while I do a system update, then I get hit. My biggest nightmare is if a Linux box goes down or I forget to manually launch its btsync process for a few days--then I know I'm in for a lengthy restoration session (or must re-sync from scratch). But the pain has taught me to always remember to manually launch the btsync process after a reboot, and a system crash is unlikely to escape my detection for very long. In your case, you have a Linux laptop, and so you have a reason to shut it down or suspend it. My NAS's are designed to be up 24/7, so I'm not in your situation. But if I installed Linux on a laptop, I would expect to have the problem you describe based on my Linux NAS experience. No clue how to fix it, but a dev will likely ask you for logs to help you troubleshoot. It would be wonderful if you could help out that way because I'm currently not set up to do that anymore. I shut down btsync on my other NAS to avoid possible problems at work.

http://syncapp.bittorrent.com/1.3.109/ http://syncapp.bittorrent.com/1.3.105/ http://syncapp.bittorrent.com/1.3.93/

It's the same symptom, but I doubt it's the same issue. You linked to a 1.3.94 discussion thread, but I've never had the old-overwrites-new problem with 1.3.109. This dreaded problem has come up from time to time over the past year. As I recall, I once solved it by redoing sync installations totally from scratch on all my devices at the same time. I'll try that with the next update. It's an annoying solution, but if it works I don't question it and move on. Regardless, I haven't seen anyone else report old-overwrites-new with 1.4, nor my other gripe of excessive Linux CPU usage. Perhaps also there's an issue of how different platforms interact? I don't see anyone else here but me who reports maintaining all three of Linux, Windows, and Android clients. That's why I'm willing to do the clean total reinstall rather than spend even more time troubleshooting when no one else's config matches mine.

How is your CPU usage? For me, 1.3.109 stays around 11%, but 1.4 jumped it to 25-35%. I mean while the process is "idling," not while its syncing after the 10-minute period.

I do regret rolling my devices back as I don't want to overdramatize my issues. I could live with the higher CPU usage on Linux for a while, but I'd first like to see what other Linux users report. But the old-overwrites-new issue--which I can't tell is due to one platform or the other, or some interaction between platforms--is a lot more discouraging. When I take the next bite of the apple, I'll try a clean re-install and re-sync from scratch on all devices simultaneously, with all data multiply backed up so that I can simply trash all new btsync installations without worry. That will be a lot of work, gathering all devices on one LAN for speed of initial sync, and then monitoring closely. So I'm going to stand pat with what works until at least the next update.

Thanks for verifying. It's weird, it just wasn't there, and now I don't want to install just to test that. If no one else has mentioned it, then maybe it was some one-off quirk that wouldn't have survived a reboot. Perhaps the devs can put a quit function in the new UI along with making it quittable via the app tray.

I'm looking at BitTorrent Sync's usage data in XPrivacy. Under the phone category, mine has accessed only: Configuration.MCC (mobile country code) Configuration.MNC (mobile network code) getNetworkOperatorName

Did the icon change? When I was running it, I didn't have a BitTorrent Sync icon in the system tray. I believe I hovered over everything to double-check.

I checked the previous download pages at http://syncapp.bittorrent.com/1.3.nn but I don't see any that include the Android app. And the devs don't want us to post "external" copies of the apk. If you're running a backup app, such as Titanium or Android Tuner, you can extract previous apk backups there. Otherwise, I guess you have to wait for the devs to put the Android apk on a download web page.

There was no BitTorrent Sync icon in my notifications area. I can no longer test because I've had to revert everything due to failures on two platforms. Even worse, reverting from 1.4.72 back to 1.3.109 required me to uninstall all data and settings on both Linux and Windows, or else 1.3.109 wouldn't launch, which is going to make testing really difficult. I really hope someone has a suggestion or a fix for the LInux and Windows versions.

PANIC: An unidentified "remote peer" keeps overwriting new with old. I change a text file on my 1.4.72 Windows laptop, and my Windows laptop's history reflects the change with entries like "a few seconds ago" etc. After a minute or so, the newer entries in the Window's history have disappeared, and the history gets rolled back to the last time one of the remote peers updated the file--which it should never have done, by the way. Then the new file gets clobbered with the old one from the remote peer. Right now, my other online Windows laptop is still on 1.3.109. This is either a 1.4.72/1.3.109 incompatibility, or something wrong with 1.4.72. I'm guessing the remote peer is my Linux NAS, which I also updated to 1.4.72. It's pretty bad that the history now only says "remote peer" rather than identify the peer. That's practically a dealbreaker right there. DOUBLE PANIC: I can't find a way to quit the Windows client in the UI. That means the only way I have to quit is to abort the process from Window's task manager. I have the feeling that's not going to lead to good outcomes. Uninstalling and reinstalling Windows 1.3.109 client. Linux client showing constant 25-35% cpu usage. Rolling Linux back to 1.3.109. At this point, I don't dare try updating my Android clients.

Try to catch the invisible handle at the right side of the column in question, then drag that. The cursor will change when you're hovering over the right spot. One beef: the history window needs to update in real time. Currently, I have to close and re-open it to see what's happened since the last time I opened. The history window is essential to maintaining a feeling of security when monitoring for a potential problem. Adding a refresh button to the history window won't really help: I want to be able to watch history as it unfolds in real time.

I didn't have time to participate in the beta, so this is my quick first impression of the new GUI: love it. I'm finding it much more convenient and informative than the previous style. DON'T PANIC! I had to hover the mouse around to "catch" the invisible thingy that allows resizing the columns. I think it only allows dragging the right side of a column. It is a bit touchy, and the bug is that the drag line is invisible, but it is draggable. Yes, it would be nice if we could scale the screen up and down. It's needlessly massive on my 1366x768, but I haven't yet looked at it on my MacBook retina whose screen I run at native resolution. I suspect it will be just fine there.

On a public WiFi network I regularly use, sync works fine when I first log in and my Windows laptop sees all my devices on another network. After two hours, my WiFi time runs out, and I have to log into it again using a different account that then gets another two hours. After logging in (and then all subsequent logins every two hours), BitTorrent Sync's "Devices" tabs shows no devices. It never sees them again unless I quit and restart the application. Then it works fine for another two hours.