v6ak

BTSync does not seem to close added files. I am recovering many files from my backup and I am getting the following error message: "Don't have permissions to write to the selected folder.". When I restart the BT sync service (i.e. killall btsync-daemon and start it again), the sync continues for some time, but it later fails again in the same way. When I look to the log file, I've recognized that it can't write to the target folder because it has reached maximum opened files. The log looks like: [20140404 15:05:37.194] SyncFilesController: failed to load torrent for file ".../apps/android-sdk-linux/platforms/android-14/data/res/drawable-hdpi/stat_sys_signal_3_cdma.png"[20140404 15:05:37.194] TorrentFile: Failed to create empty suffix for file ".../apps/android-sdk-linux/platforms/android-14/data/res/drawable-hdpi/stat_sys_signal_4_cdma.png" - 24[20140404 15:05:37.194] SyncFilesController: failed to load torrent for file ".../apps/android-sdk-linux/platforms/android-14/data/res/drawable-hdpi/stat_sys_signal_4_cdma.png"[20140404 15:05:37.194] TorrentFile: Failed to create empty suffix for file ".../apps/android-sdk-linux/platforms/android-14/data/res/drawable-hdpi/stat_sys_signal_evdo_0.png" - 24[20140404 15:05:37.194] SyncFilesController: failed to load torrent for file ".../apps/android-sdk-linux/platforms/android-14/data/res/drawable-hdpi/stat_sys_signal_evdo_0.png"...[20140404 15:15:18.506] Failed file save: .../sync.dat.new It does not reach the global system limit, just the per-process limit. I've increased the limit from 1024 to 4096, but it does not solve the problem. It seems that the app simply does not close the newly created files. When I run watch 'lsof | grep btsync-da | grep REG | wc -l', the number of opened files continuously grows. My BTSync and system versions: % dpkg -l | grep btsyncii btsync 1.3.0-1 Private network P2P file synchronisation daemon(s)ii btsync-common 1.3.80-1 Private network P2P file synchronisation daemonrc btsync-gui-gtk 0.8.1-2 Full GTK based Linux GUI for BitTorrent Sync% lsb_release -aNo LSB modules are available.Distributor ID: UbuntuDescription: Ubuntu 12.04.4 LTSRelease: 12.04Codename: precise

Is .SyncID somehow related to the secret? Can I extract the secret from it somehow? I've tried to convert it to base32 (and possibly prepend a byte to match the resulting 33B length), but it does not seem to be related. But there are more base32 variants and more ways to transform the binary.

I am not sure if it is wise to backup the root directory, because: a) BT sync AFAIK does not distinguish between a symlink and a regular file/directory, so there can be an infinite recursion. I am not sure if BT sync can handle /proc, /sys and /dev properly. c) Did you consider permissions? d) You hay have connected some other device (e.g. an external HDD or an USB stick), which would be added to the sync. e) Do you really need a backup of /bin, /boot and so on?

I don't think that filesystem watching is the issue. Filesystem can be watched by inotify and it does not require any wakelock. There is a different issue, though. The sync app uses network connections. Unlike Dropbox, it is probably not connected to a single server, but looks for other peers, which may require a wakelock. There are some possible ways around this issue: a) A simple but not very powerful approach: Use a slightly centralized solution that notifies (by GCM) the phone about other peers. Note that there is probably no other way on iPhone, so something similar will be probably implemented. Disadvantages: SPoF + need to have an internet connection. b ) Optimize peer connection to be push-like, if not optimized. c) I am not sure if UPnP is battery friendly, i.e. if it can run completely without a wakelock. If not, I suggest a more battery friendly mode on background that possibly turns UnPNP totaly out. Note: If neither b ) nor c) was an issue, there should be no reason for wakelock.