lpa

Members
  • Content Count

    4
  • Joined

  • Last visited

About lpa

  • Rank
    New User

Profile Information

  • Gender
    Not Telling
  1. I think I may have found the problem. "storage_path" directory was not writable for user that runs btsync. And if it is empty, it tries to create directory ".sync" where binary is located, on Arch system it is /usr/bin. This directory, of course, is not writable for user. Systemd journal indicated following problems: SyncDb: failed to begin transaction to save metadata - 21Failed file save: /usr/bin/.sync//sync.dat.newShutdown. Saving config sync.datFailed file save: /usr/bin/.sync//settings.dat.newSo I changed storage_path value to "/home/user/.sync" and everything worked. Have not seen files overwritten with old ones since.I must note, that all 3 of my linux nodes had this storage_path write problem, but since 2 of them where online most of the time, I did not experience any problems with wrong files. What do I think about this? 1. BTSync node, that cannot write to "storage_path", should not push its old files to other nodes. Such behavior is fundamentally against the whole purpose of this software. As I see it, such node, should either "just sit" and do nothing or not start at all. Giving clear error messages that it needs storage_path for functioning properly. 2. The two slashes in error log is confusing. At first I suspected, that the software tries an invalid path. Can anyone, having same problem, confirm this? Thanks!
  2. All due respect, I do not need a lesson on Windows vs. Linux filename limitations. As I said earlier, the filenames are fine. I will try to illustrate with an example. Laptop was offline, I changed text file "test", turned on laptop it sent old version of "test" back to other nodes. The outputs are from each machine. Laptop before turning on btsync: lpa@laptop % stat test File: ‘test’ Size: 3 Blocks: 8 IO Block: 4096 regular fileDevice: fe06h/65030d Inode: 13635201 Links: 1Access: (0644/-rw-r--r--) Uid: ( 1000/ lpa) Gid: ( 100/ users)Access: 2013-10-03 19:30:49.000000000 +0300Modify: 2013-10-03 19:30:49.000000000 +0300Change: 2013-10-03 19:31:59.143203957 +0300 Birth: -Laptop after: lpa@laptop % stat test File: ‘test’ Size: 3 Blocks: 8 IO Block: 4096 regular fileDevice: fe06h/65030d Inode: 13635201 Links: 1Access: (0644/-rw-r--r--) Uid: ( 1000/ lpa) Gid: ( 100/ users)Access: 2013-10-03 19:30:49.000000000 +0300Modify: 2013-10-03 19:30:49.000000000 +0300Change: 2013-10-03 19:31:59.143203957 +0300 Birth: -Server before: lpa@server % stat test File: ‘test’ Size: 9 Blocks: 8 IO Block: 4096 regular fileDevice: fe00h/65024d Inode: 786920 Links: 1Access: (0644/-rw-r--r--) Uid: ( 1000/ lpa) Gid: ( 100/ users)Access: 2013-11-04 00:08:26.000000000 +0200Modify: 2013-11-04 00:08:26.000000000 +0200Change: 2013-11-04 00:08:37.882082822 +0200 Birth: -Server after: lpa@server % stat test File: ‘test’ Size: 3 Blocks: 8 IO Block: 4096 regular fileDevice: fe00h/65024d Inode: 786920 Links: 1Access: (0644/-rw-r--r--) Uid: ( 1000/ lpa) Gid: ( 100/ users)Access: 2013-10-03 19:30:49.000000000 +0300Modify: 2013-10-03 19:30:49.000000000 +0300Change: 2013-11-04 00:21:04.481515684 +0200 Birth: -lpa@server % stat .SyncArchive/test File: ‘.SyncArchive/test’ Size: 3 Blocks: 8 IO Block: 4096 regular fileDevice: fe00h/65024d Inode: 787922 Links: 1Access: (0644/-rw-r--r--) Uid: ( 1000/ lpa) Gid: ( 100/ users)Access: 2013-11-04 00:08:37.000000000 +0200Modify: 2013-11-04 00:08:37.000000000 +0200Change: 2013-11-04 00:08:37.882082822 +0200 Birth: -Desktop before: lpa@desktop % stat test File: ‘test’ Size: 9 Blocks: 8 IO Block: 4096 regular fileDevice: fe05h/65029d Inode: 5505772 Links: 1Access: (0644/-rw-r--r--) Uid: ( 1000/ lpa) Gid: ( 100/ users)Access: 2013-11-04 00:08:26.000000000 +0200Modify: 2013-11-04 00:08:26.000000000 +0200Change: 2013-11-04 00:08:38.392873583 +0200 Birth: -Desktop after: lpa@desktop % stat test File: ‘test’ Size: 3 Blocks: 8 IO Block: 4096 regular fileDevice: fe05h/65029d Inode: 5505772 Links: 1Access: (0644/-rw-r--r--) Uid: ( 1000/ lpa) Gid: ( 100/ users)Access: 2013-10-03 19:30:49.000000000 +0300Modify: 2013-10-03 19:30:49.000000000 +0300Change: 2013-11-04 00:21:06.153467994 +0200 Birth: -lpa@desktop % stat .SyncArchive/test File: ‘.SyncArchive/test’ Size: 3 Blocks: 8 IO Block: 4096 regular fileDevice: fe05h/65029d Inode: 5505753 Links: 1Access: (0644/-rw-r--r--) Uid: ( 1000/ lpa) Gid: ( 100/ users)Access: 2013-11-04 00:08:38.000000000 +0200Modify: 2013-11-04 00:08:38.000000000 +0200Change: 2013-11-04 00:08:38.392873583 +0200 Birth: -Windows desktop before: > dir2013.11.04. 00:08 9 testWindows desktop after: > dir2013.10.03. 18:30 3 test.SyncArchive> dir2013.11.04. 00:21 9 testLaptop obviously lacks file "test" in .SyncArchive since it ignored updated file and pushed its old one.
  3. No. Happens to all lowercase. Besides, other Linux hosts would behave same if it were case sensitivity issue.
  4. BTSync overwrites newer files with older ones. This happens if files have been modified while one client is offline. When that client comes online BTSync overwrites files with that client's (old) versions. Why? When I look at .SyncArchive on other clients I can see the deleted newer files with newer modification times than the old file, which overwrote them. I have 4 machine setup: 1 always online, Linux (server); 2 mostly(just occasional restarts) online, one Linux, one Windows; 1 laptop, online when needed, Linux. (this is the client, that propagates old file versions) All 3 Linux machines have same config, so I cannot blame laptop's config. Yes, I have checked clocks on all machines. And yes, permissions are fine, can create and modify files. (Anyway it would be lame to overwrite new files, because one client has old read-only copies) I do not appear to be alone with this problem: http://forum.bittorrent.com/topic/24146-sync-overwrites-new-files-if-a-node-is-away-for-a-while/ http://forum.bittorrent.com/topic/22382-new-files-overwritten/ http://forum.bittorrent.com/topic/24058-btsync-deleted-new-version-of-files-and-synced-the-old-one/ http://forum.bittorrent.com/topic/23272-issue-1170-replaces-new-files-with-older-ones-from-remote-server/ http://forum.bittorrent.com/topic/20104-reproducible-data-loss-same-as-old-file-overwriting-new-files/ http://forum.bittorrent.com/topic/25081-sync-to-computer-with-old-version-file/ http://forum.bittorrent.com/topic/19668-help-newer-files-overwritten-by-older-files/