mcv

New Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by mcv

  1. Sure, I enabled logging now. I don't remember if I haven't had hard restarts recently on my notebook, but I did have on another machine - but sync works fine there. But since I have an ATI card there and there's problem with drivers, I'll start backing up the sync config directory there, too. :-) I see, then I'll upgrade my btsync. :-)
  2. Hi. Today I waited a bit to see my video recorded on my phone transferred to my notebook, but it wasn't showing. So I loaded the web interface and I saw the first run page (Link devices dialog). Suddenly btsync lost all of its configuration? I checked .config/btsync/btsync.conf and it was still there, as it should, apart from many other files. I haven't upgraded my system recently and haven't upgraded btsync. The version is 2.0.128 (36). Any ideas? Is this problem known? Will upgrading solve the issue? I see that sync.dat file is 1307 bytes, whereas sync.dat from a backup some time ago is 50427. Nevertheless, I restored my whole .config/btsync from backup and it seems to work now. I hope it won't tangle my synchronized directories.
  3. I'm having the same dialog keeping popping up on Android. I needed to cleanup the mess that BTSync 2.0 made with my folders after upgrading from 1.4, so I disconnected everything and I tried to reconnect everything cleanly. I removed the .sync directory from the Android, but it wouldn't help. Arrgh, after removing directory on my Android and trying to add it from shared QR code, BTSync crashes every time.
  4. Can you check if all of your machines have synchronized system clocks? It happened to me a couple of times that new versions were replaced with old files. I found that at least one reason for that is desynchronized clock on one of the machines. It's easy and always reproducible. Since then I enabled automatic clock syncing from NTP on all of my systems. It's a pain that BTSync relies on system clock so heavily instead of doing some sort of own clock synchronization. Each instance could synchronize its own clock with the rest of BTSyncs, then calculate the difference between its clock and system clock and use such "corrected" time to see what files are really the new ones.
  5. Hi. I found a problem with Sync that can cause data loss. The problem is related to filesystems that don't distinguish upper/lower case characters in latin alphabet, and Sync handles this issue very bad. My short story: I had directory named 'xefis' and later, temporarily I created a file named 'XEFIS' with some links inside (purposely named the same with only case difference to remember that they're related). After a while my 'xefis' directory was all gone, only the 'XEFIS' file remained on all connected devices, and the "offending" one (Android) was unable to sync completely. Thank goodness, there was .sync/SyncArchive, but it also included old files, so I have a mess in my 'xefis' directory right now. So some filesystems don't see any difference between file named 'x' and 'X'. If Sync runs on multiple platforms where on one this is allowed and on another it is not (say: Linux and Android with FAT SD card), so essentially Sync is trying to reconcile two worlds, which can not be done perfectly. So if I have files 'x' and 'X' in the same directory, two things can be observed: - Sync gets stuck with syncing, - one of the files gets deleted everywhere (on all connected nodes). Luckily data is still in SyncArchive, but if one doesn't immediately notice this, he may lose his data forever. What I would expect it to do: - identify the problem (filename conflict) on systems where it happens (not everywhere, I think it's unnecessary) - _not_ sync the conflicting files. If there's a conflict - do nothing, especially _do not replace or overwrite or delete_ one of conflicting files. Show a message instead, don't just stop syncing for unknown reasons. Here I assumed that no-one wants to lose their data, but If there's anyone who would need such behavior (overwriting files), maybe implement it as an configuration option? Please note that the problem is not really related to certain operating systems, but rather to the filesystems. As far as I know, it's possible to get POSIX-way of handling of file names on Windows, on the other hand being on Linux doesn't necessarily incur that case-distinguishing happens - Sync could be as well configured to work on a FAT filesystem under Linux (it can happen on Android). So the solution should be filesystem aware, not OS-aware.