DFix

Copied File Insync Folders Are Sometimes Reseted At 0 Ko

Recommended Posts

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

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by lmdp

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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! 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now