samuelkadolph

Looks like it was fixed in 2.6.3. The changelog says "Fixed moving files to Archive and replacing them with 0 bytes files" and I just tested it with a single file and git repo and it didn't zero out newly created files. That said, I'll be using read-only sync to my backup servers from now on.

I'm also having this issue. In my case, I've narrowed it down to an issue with timestamps with resilio on my server through an NFS share to my NAS. Running resilio with a local drive or resilio on my NAS directly does not cause the issue. Upon sync, any new file is truncated and the original moved to .sync/Archive. $ date > date.txt $ cat date.txt Tue 8 Jan 2019 02:13:15 EST $ cat date.txt Tue 8 Jan 2019 02:13:15 EST $ cat date.txt $ cat .sync/Archive/date.txt Tue 8 Jan 2019 02:13:15 EST And here's the relevant log portion: [20190108 07:13:26.303] MC[1CEA] [CE1C]: processing nodes message for /date.txt [20190108 07:13:26.303] MC[1CEA] [CE1C]: will request files for /date.txt [20190108 07:13:26.303] MC[1CEA] [CE1C]: sending get_files message [20190108 07:13:26.357] SF[1CEA] [CE1C]: Received request "files" [20190108 07:13:26.357] MC[1CEA] [CE1C]: processing files message with 1 files [20190108 07:13:26.357] MC[1CEA] [CE1C]: Local file date.txt is newer than remote t:1546931596/1546931595 ot:55153/84032 o:107315CCE4BFA5AF34FC9AB8C36503C2F43441C5/101B4EBDDDC6B0257696FB55C5CB9192212ACE1C [20190108 07:13:26.358] MC[1CEA] [CE1C]: will send file /date.txt Comparing date on both my servers vs my mac's time shows they are in pretty much perfect sync. I'm running 2.6.2 on all my devices except my NAS which has 2.5.9. I agree, this is a very dangerous bug that was introduced recently to resilio and makes it hard to trust and rely on.