DFix Posted December 20, 2014 Report Share Posted December 20, 2014 Hi Folks, It seem there is a strange bug across my small network of Synced folders : when I copy a file in a Synced folder, the file is sometimes reseted at 0 ko : It is copied correctly, with its right size, but a few seconds after the sync begins, the file may be rewrited at 0 ko, causing a loss of data. I have 8 computers in my network, this bug can happen on all of them (all have last version, 1.4.103). I doesnt happen each time I insert a new file in a synced folder, but it still happens pretty often (I have to be carefull the file is correctly copied, I lost some important stuff once or twice). I also happens when I save a downloaded file from Firefox in a synced folder : same bug. Any advice ? Thanks a lot ! Jeremy Quote Link to comment Share on other sites More sharing options...
lmdp Posted January 5, 2015 Report Share Posted January 5, 2015 Hi, Since we use Btsync on production we have noticed a random bug, quite rare at the begining (a few times a week) but now systematic for a specific workflow. When syncing newly created or saved files, some of them are randomly wiped out and replaced by a 0 bytes version and the real file is moved to .sync/Archive. The other nodes then replicate the empty files, and sometimes keep the neighbor .!sync.If the owner try to replace the empty file by the archive one, the file is quickly moved again to the archives. To get rid of them, every node have first to delete the empty files. This may be related to large files with long writing times, but it happened exceptionally just by moving files of a few MB. It happened time to time when saving PSD files of 50-100 MB, but it is now systematic when rendering video files (ex. when rendering eight videos trough After Effects, approximately two will be emptied). Is it a known issue ? Is there any way to get rid of it ?Thanks. PS : The production is ~100GB distributed to 3 (distant) PC and a Mac, constantly evolving (~300 files or ~10GB a day). Quote Link to comment Share on other sites More sharing options...
jmr01 Posted January 6, 2015 Report Share Posted January 6, 2015 We have started getting a similar issue over the last 2 days. Sync has been working perfectly since we installed 1.4.103 until now. A new file is created on a Windows 7 PC. This syncs with a Netgear Ready NAS but creates a 0KB copy of the file which is then synced back to the original PC overwriting the file with a 0KB copy! This doesn't happen every time but is becoming more regular. Any ideas why this is happening? Quote Link to comment Share on other sites More sharing options...
DFix Posted January 7, 2015 Author Report Share Posted January 7, 2015 Thanks for feedback, I still have that bug with v1.4.106. It does not depend on size file here : it can happen with 10 ko file or with 50 mo file randomly. It seems that some file are particularly reluctant (some just don't want to be synced, and remain at 0 ko : I have to rename them, and copy them again to make it work). It never happens when I modify a file already synced. Any idea is much appreciated Quote Link to comment Share on other sites More sharing options...
jmr01 Posted January 7, 2015 Report Share Posted January 7, 2015 I'm wondering if the NAS drive is part of the problem. Do either of you have a NAS drive synced with the problem folders? The original files are moved to .sync/Archive. I've found that if we open the files from the Archive and re-save them so that the date stamp changes then copy them back to the original synced folder they will then sync correctly. This problem is only with new files. Quote Link to comment Share on other sites More sharing options...
lmdp Posted January 7, 2015 Report Share Posted January 7, 2015 (edited) No NAS drive involved here. Two production PC and a Mac. Latest version of Btsync by the way.In my case as I said this happened a few times by modifying a large file, with several seconds of writing time. But if this is systematic with newly rendered files by After Effects, it pretty much never happens with same type of files (video file created/writed during several minutes) rendered by Blender for example...This is really problematic to work with... Edit : I confirm that it totally happens with small files too (ex. creating an image sequence), with a probability of approx. 1 on 30. Edited January 8, 2015 by lmdp Quote Link to comment Share on other sites More sharing options...
DFix Posted January 8, 2015 Author Report Share Posted January 8, 2015 Anyone has a solution ? I agree with lmdp, this is extremly annoying... Quote Link to comment Share on other sites More sharing options...
thgood Posted January 9, 2015 Report Share Posted January 9, 2015 This is happening to us as well using version 1.4.103, with typical document files < 1mb shared between just two peers on windows server 2012. I'd call it a major issue. Quote Link to comment Share on other sites More sharing options...
vivitron Posted January 12, 2015 Report Share Posted January 12, 2015 We just upgraded to 1.4.103 to fix the newer files overwriting older files issue and then this popped up. It happens randomly and we just encounter 0 byte files. It seems that recreating the same file creates the same issue. Unfortunately the test files we have are sensitive and cannot be shared. Not stable and a pretty major issue. 1.4.103 shouldn't be in the wild with these types of issues. Makes btsync very unreliable. Quote Link to comment Share on other sites More sharing options...
DFix Posted January 20, 2015 Author Report Share Posted January 20, 2015 Has anyone found a solution ? Any word from Sync Team ? Quote Link to comment Share on other sites More sharing options...
Helen Posted January 21, 2015 Report Share Posted January 21, 2015 @all, Team knows about it and is working on a fix. Please follow this instruction to collect logs and send them to syncapp@bittorrent.com In the mail put a link to this topic and, please indicate which exactly files are reseted (to trace them down in the logs) and on which of the peers you see it happen. Thank you! Quote Link to comment Share on other sites More sharing options...
thgood Posted March 23, 2015 Report Share Posted March 23, 2015 Has this been fixed?Is there a related bug ticket?Thanks Quote Link to comment Share on other sites More sharing options...
Helen Posted March 25, 2015 Report Share Posted March 25, 2015 In those cases where the problem was caused by Sync's code, it was fixed in Sync 2.0. However, this problem also has a number of other causes depending on the workflow and environment. Such cases still require debugging Quote Link to comment Share on other sites More sharing options...
risouplny Posted December 10, 2018 Report Share Posted December 10, 2018 Hello, After three years is this bug back. I'm using version 2.6.1 (1319) on my two PC with Ubuntu and Synology NAS server. When I update actually synced files, all is OK. But when I add new file, synchronization with NAS is OK. Then when I start another computer after synchronization with 50% probability is size 0 Bytes. I tried update version on NAS to 2.6.2 but not success. Can you help me? Quote Link to comment Share on other sites More sharing options...
klues Posted December 30, 2018 Report Share Posted December 30, 2018 Same issue here again. Just had to recover dozens of files from the .archive folder because all new files were overwritten by empty 0kB files. This is extremely annoying and makes Resilio Sync useless and even dangerous for data security. Quote Link to comment Share on other sites More sharing options...
samuelkadolph Posted January 8, 2019 Report Share Posted January 8, 2019 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. Quote Link to comment Share on other sites More sharing options...
mustha Posted January 8, 2019 Report Share Posted January 8, 2019 I'm also having this issue. I keep having to check if the file is really properly saved or not. But this is not happening across all folders but in some specific ones. I think it is related with folders which have been disconnected and are reconnected at the same path (i.e. the same folder to which resilio was syncing before). Quote Link to comment Share on other sites More sharing options...
klues Posted January 12, 2019 Report Share Posted January 12, 2019 I just downgraded to version 2.5.12 and it seems that the issue doesn't exists there. Before I had 2.6.1 where the issue existed. Quote Link to comment Share on other sites More sharing options...
samuelkadolph Posted January 30, 2019 Report Share Posted January 30, 2019 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. Quote Link to comment Share on other sites More sharing options...
risouplny Posted January 31, 2019 Report Share Posted January 31, 2019 11 hours ago, samuelkadolph said: 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. Great, now I'm waiting for automatic update in linux via PPA resources... Quote Link to comment Share on other sites More sharing options...
risouplny Posted February 8, 2019 Report Share Posted February 8, 2019 Version 2.6.3 solves this problem... Quote Link to comment Share on other sites More sharing options...
Rich Posted February 10, 2019 Report Share Posted February 10, 2019 Something is still wrong. I am running version 2.6.3 1340 and this problem still exists. I am syncing my user/data drive "D" on Windows 10 to my raspberry pi backup server with updated raspbian. My entire "D" drive has ALL of the files listed as 0 byte files. When I open up the archive I can see all my files there. I am running in read-write mode. This is my very first time in running resilio and this FREAKED me out. What do I do? Quote Link to comment Share on other sites More sharing options...
klues Posted August 11, 2019 Report Share Posted August 11, 2019 Same here. After sticking to version 2.5.12 for a while where this issue doesn't exist, I upgraded to 2.6.3 1340 where the changelog states that this issue is fixed, but it is NOT! Again had a bunch of files that were resetted to 0kb. This is really unacceptable - how to trust in a tool that actually deletes your data?! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.