Files Become Zero Byte After Success Upload/Download

Orcun · November 23, 2018

Hello,

I'm having sync issues. Files become zero byte file after successfully transferring them. I cannot figure out whats happening.

You can find the log file attached.

syncLogZeroByte.txt

motonuke · November 25, 2018

I'm having the same issue, I've lost a bunch of pictures on my phone because of this. Hope we can find a solution, for now I cannot trust this app.

Orcun · November 25, 2018

This is a very weird issue. Noone can help. I've lost files as well. I can't understand anything from the debug logs as well.

Orcun · November 26, 2018

Anyone? Any officials from Resilio?

Timbo · November 27, 2018

I've never liked their debug logs, as you need a decoder ring to make sense of errors, but I'd think you need the log from the other side. This log is basically just saying, "I got a file but it was size: 0". Need to know why the other side is telling you its a size 0 file.

motonuke · November 27, 2018

In our case, if debugging wasn't already enabled, who in their right mind is going to turn that on and potentially lose more data?

Orcun · November 27, 2018

Which other side? Can you see an id ?

Eric Mathieu · December 25, 2018

I am getting the same issue with my Raspberry Pi 2, v2.6.1

Timbo · December 25, 2018

1 hour ago, Eric Mathieu said:

I am getting the same issue with my Raspberry Pi 2, v2.6.1

They're up to 2.6.2 now.

smee0815 · January 6, 2019

Same problem here, using version 2.6.2 on Windows 10 and Raspberry. Luckily, the original versions seem to be present in the .sync/Archive subfolder, so I was able to restore them manually. But still, this bug severely reduces my confidence in this product. I need to constantly monitor folders with newly added files.

After adding a file on a Windows machine to a folder synched to the raspberry, the only line in the logfile on the raspberry that contains the filename is

Quote

[20190110 19:47:30.716] TF[8539] [0x60b560d0][/media/hdd-1tb/sync/foldername/xxxxfilesizetestxxxx]: error: "initial recheck" (1)

Edited January 10, 2019 by smee0815
add log file line

AlexC · January 22, 2019

On 1/6/2019 at 2:25 PM, smee0815 said:

Same problem here, using version 2.6.2 on Windows 10 and Raspberry. Luckily, the original versions seem to be present in the .sync/Archive subfolder, so I was able to restore them manually. But still, this bug severely reduces my confidence in this product. I need to constantly monitor folders with newly added files.

After adding a file on a Windows machine to a folder synched to the raspberry, the only line in the logfile on the raspberry that contains the filename is

This issue was fixed in 2.6.3 version

Rich · February 10, 2019

I experienced this same problem running 2.6.3 (1340) on windows 10 and raspberry. It's not fixed.

I do see them in the .sync/Archive folder.

I just don't know: 1-how to get them out of the archive folder, and 2-how to prevent this from happening again.

As a NEW user - I need some help. Thanks.

Orcun · February 10, 2019

38 minutes ago, Rich said:

I experienced this same problem running 2.6.3 (1340) on windows 10 and raspberry. It's not fixed.

I do see them in the .sync/Archive folder.

I just don't know: 1-how to get them out of the archive folder, and 2-how to prevent this from happening again.

As a NEW user - I need some help. Thanks.

Is the raspberry version also 2.6.3?

Rich · February 10, 2019

No. It is 2.6.1 1319

Orcun · February 10, 2019

9 minutes ago, Rich said:

No. It is 2.6.1 1319

That's probably where the problem is.

Type the following

wget https://download-cdn.resilio.com/2.6.3/Debian/resilio-sync_2.6.3-1_armhf.deb
sudo dpkg -i resilio-sync_2.6.3-1_armhf.deb

This will override the previous installation. Then check from the web interface that Raspberry Pi is also running 2.6.3

Rich · February 10, 2019

16 minutes ago, Orcun said:

Is the raspberry version also 2.6.3?

1 minute ago, Orcun said:
That's probably where the problem is.

Type the following
wget https://download-cdn.resilio.com/2.6.3/Debian/resilio-sync_2.6.3-1_armhf.deb
sudo dpkg -i resilio-sync_2.6.3-1_armhf.deb
This will override the previous installation. Then check from the web interface that Raspberry Pi is also running 2.6.3

When I update to this version on the Pi, what will it do to the files in the archive?

Orcun · February 10, 2019

5 minutes ago, Rich said:

When I update to this version on the Pi, what will it do to the files in the archive?

To the archieved files? Nothing. They stay there. You can put them back after you update. Manually copy the files in the archieve to their locations after you update.

Rich · February 12, 2019

On 2/10/2019 at 11:08 AM, Orcun said:

To the archieved files? Nothing. They stay there. You can put them back after you update. Manually copy the files in the archieve to their locations after you update.

Getting both machines on the same version 2.6.3 seemed to fix the problem for me. Thanks for your help!

dankshit · September 16, 2021

This CRAP just happened to me today!

Latest Resilio Sync fresh install onto RPi4 running Kali 21.x (aarch64 - on a fresh install of kali)... I'm using Resilio Sync Pro - I have a pro a license.

So I try and sync connect a share (copy + paste key) after fresh install of RSLSync, client (using web UI to localhost) it tells me "database error" with nothing specific (e.g. WHAT IS THE ERROR?)... I removed it (Resilio Sync) completely (apt purge), rebooted, then re-installed and same issue, so I gave up, powered off the Pi running Kali...

But now ALL my sync files in that share on ALL my OTHER computers are now ZERO bytes in size! This is a MAJOR FLAW and a SERIOUS BUG!

This is on Ubuntu 20.04 x86_64, Raspbian Buster arm64, Ubuntu 21.04 x86_64 and arm64 - and MacOS on Macbook Pro M1!!!

I've been considering shopping around for another self-hosting cloud sync solution - and this might just push me elsewhere...

Note : it's not a "disaster" because the original files are in $SHARE/.sync/Archive - but - this is a REALLY CRAP gotcha... REALLY Annoying too! All my shell scripts I used for work are in that share and now they're ALL ZERO BYTES!

Seriously CRAP result, you get zero stars out of five from me!!! ~/bin is a symlink to a "bin" directory in a shared folder in ~/ResilioSync/ - on my Macbook Pro M1 :

╭─x@methone.local ~/bin
╰─➤  find . -maxdepth 1 -size 0k -ls
43152616        0 -rw-r--r--    1 x                staff                   0 16 Sep 16:43 ./pigsies.bash
43152557        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./unfux.bash
43152544        0 -rw-r--r--    1 x                staff                   0 16 Sep 16:43 ./rs-helpoid.bash
43152538        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./nodoze.bash
43152522        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./McPasta
43152519        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./ENIPee.bash
43152527        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./eggo.bash
...
...
43152518        0 -rw-r--r--    1 x                staff                   0 16 Sep 16:43 ./3users.txt
43152540        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./nuku.bash
43152543        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./queue.cue
43152517        0 -rw-r--r--    1 x                staff                   0 16 Sep 16:43 ./0.0.10.not.finished
43152524        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./bashtop
43152550        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./splitmp3.bash
258962        0 -rw-r--r--    1 x                staff                   0  6 Feb  2019 ./.stfolder
43152536        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./neofetch
43152556        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./tvhead.bash
43152532        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./mailpdf.bash
43152555        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./tranny.bash
...
43152552        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./steamlink-pi.bash
43152545        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./s3cr3thy.bash
43152534        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./mcshow.bash
43152615        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./boris-flood.cue
43152523        0 -rw-r--r--    1 x                staff                   0 16 Sep 16:43 ./ZSH.zshrc
43152520        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./EmPee.bash
43152553        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./sunzolio.bash
43152542        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./purvue.bash
43152549        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./spectre-meltdown-checker.sh
43152546        0 -rw-r--r--    1 x                staff                   0 16 Sep 16:43 ./screep.bash
43152533        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./manual_mailpdf.bash
43152558        0 -rw-r--r--    1 x                staff                   0 16 Sep 16:43 ./upgytdl.bash
43152547        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./shitlist.bash
43152554        0 -rw-r--r--    1 x                staff                   0 16 Sep 16:43 ./thou-audiotree.cue
43152541        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./pastebin.bash
43152525        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./clockuld.bash
43152529        0 -rw-r--r--    1 x                staff                   0 16 Sep 16:43 ./gitfuckery.bash
43152526        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./docxfind.bash
43152548        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./slappem.bash
43152539        0 -rw-r--r--    1 x                staff                   0 16 Sep 16:43 ./nuku.ascii
43152559        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./watchtv.bash
...
43152537        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./nocmur02.bash
43152521        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./MUZ.bash
43152551        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./spudchuq.bash
43152535        0 -rwxr-xr-x    1 x                staff                   0 16 Sep 16:43 ./merdepee.bash

RPi4 running "buster" on arm64 :

╭─x@beere253 ~/bin  
╰─➤  find . -maxdepth 1 -type f -size 0k -ls
   527211      0 -rw-r--r--   1 x        x               0 Sep 16 16:43 ./pigsies.bash
   527235      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./pastebin.bash
   527246      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./spectre-meltdown-checker.sh
   527344      0 -rw-r--r--   1 x        x               0 Sep 16 16:43 ./upgytdl.bash
   527355      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./spudchuq.bash
   527312      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./neofetch
   527204      0 -rw-r--r--   1 x        x               0 Sep 16 16:43 ./0.0.10.not.finished
   519542      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./purvue.bash
   527283      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./watchtv.bash
   527360      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./slappem.bash
   527243      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./nocmur02.bash
   527455      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./tranny.bash
   517982      0 -rw-r--r--   1 x        x               0 Feb  6  2019 ./.stfolder
   519143      0 -rw-r--r--   1 x        x               0 Sep 16 16:43 ./thou-audiotree.cue
   527255      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./docxfind.bash
   520041      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./boris-flood.cue
   522009      0 -rw-r--r--   1 x        x               0 Sep 16 16:43 ./screep.bash
   519350      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./sunzolio.bash
   519124      0 -rw-r--r--   1 x        x               0 Sep 16 16:43 ./rs-helpoid.bash
   519142      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./mailpdf.bash
   521995      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./queue.cue
   527385      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./MUZ.bash
   527306      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./eggo.bash
   527240      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./unfux.bash
   519253      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./tvhead.bash
   527314      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./ENIPee.bash
...
   519144      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./splitmp3.bash
   521997      0 -rw-r--r--   1 x        x               0 Sep 16 16:43 ./gitfuckery.bash
   527357      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./bashtop
   527358      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./mcshow.bash
   527378      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./EmPee.bash
   527454      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./merdepee.bash
   527266      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./clockuld.bash
   527392      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./manual_mailpdf.bash
   527248      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./shitlist.bash
   526825      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./nuku.bash
   527176      0 -rw-r--r--   1 x        x               0 Sep 16 16:43 ./ZSH.zshrc
   527380      0 -rw-r--r--   1 x        x               0 Sep 16 16:43 ./nuku.ascii
   527323      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./steamlink-pi.bash
   527207      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./McPasta
   519140      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./s3cr3thy.bash
...
   519625      0 -rw-r--r--   1 x        x               0 Sep 16 16:43 ./3users.txt
...
   527391      0 -rwxr-xr-x   1 x        x               0 Sep 16 16:43 ./nodoze.bash

This is a NIGHTMARE to go and fix now!!! I now have to manually HUNT and PECK through EVERY F--KING FOLDER and figure out what files got ZEROED 'cause not every file got ZEROED - and - some files are SUPPOSED to be ZERO anyway!

Can I even ever trust your product again???

I'm half thinking I might REMOVE that share from Resilio Sync, rebuild that folder tree and files again from scratch/backups, then re-share - but - that's a REAL F--KING PAIN in the @RSE! I have up to 13 computers subscribed to this share...

MAJORLY PISSED OFF disgruntled potentially former user of your (formerly good - but now RUBBISH) product...

dankshit · September 16, 2021

It gets worse!!!

In some cases, the backup of the zero byte original file doesn't have the same name...

e.g. in $SHARE/bin/

bashtop (is zero btyes)

The backup in $SHARE/.sync/Archive/bin isn't called "bashtop" - it's called bashtop.2

So I can't just wildcard everything back again - I have to granularly manually locate EVERY F--KING F--KED up file and recover it...

This is complete bullshit... I'm going elsewhere, and whereever I go, I'm giving Resilio Sync ZERO stars out of FIVE stars...

Folks - DO NOT RELY ON THIS PRODUCT - it's not ready for primetime - and you'll get use to it (I've been using Pro for 3 years) then Mr Murphy will come along and F--K YOU OVER GOOD AND PROPER!

In the example above - "bashtop" isn't necessarily "my" shell script - but this example holds true for everything else...

And - it wasn't anything "I did" that zeroed all these files - it was YOUR PRODUCT!

Jamieson · October 27, 2021

what I've discovered... On Mac OS anyway…

The files being moved to archive and replaced with zero-byte files still happens every single time I copy files to the synced folder. I now know exactly what is happening;

MacOS creates temporary zero-byte placeholder files when copying files. They’re the little greyed-out ones that show until the actual file is copied to a folder. Resilio sync is quickly syncing those placeholder zero-byte files to computer 2 before the actual files are finished copying to the sync folder locally on computer 1. Since those zero-byte placeholder files have now made it to computer 2 and have a newer timestamp than the actual files, Resilio Sync is determining that they should be kept instead of the actual files, so it is back-syncing those zero-byte files from computer 2 over the actual files on computer 1, and moving the actual files into the archive folder.

The only way to prevent this is to close Resilio Sync completely while copying any files to the sync folder. This way Resilio doesn't have the chance to sync those temporary zero-byte placeholder files in the first place.

Hopefully this can be fixed in an update

Pirate · March 9, 2022

i have 6 macs on a wifi hotspot network and my iPhone, and in all the computers there are about 150 zerok files. I had some wifi hotspot issues, couldn't sync photos and couldnt sync them to iCloud either (not that I want to but only so I don't lose them. The zero K files corresponded 99% with the current batch of photos in the phone, which are still ok. Resilio 2.7.2 and backup folders at 5 disks are all so I don't have to use cloud, normally. anyway, I trashed all the zero k files on one computer, then synced it to the phone again, and all the files were zero K again. I think when the iPhone had an issue with wifi (deleting the VPN network cleared it up), it must have gotten the filenames transferred, but not the content. Then when I deleted the empty files, they started getting written again from the other computers, at 0bytes, rather than a good copy from the phone, which only seems to happen when you enter the code and touch the line for your phone it starts to sync. ANYWAY sync is paused on all the computers for now, until i solve this. I plan to use use an iphone flash USB disk to backup the phone photos directly (a PNY DUOlink). Then probably i will try to drag or sync to the cloud, or not. i just don't like it when I can't do the moving of the actual file. Then I plan to deleete the empty files from one computer, and turn on sync. then move to the next computer one computer at a time. this will prevent empty files from transferring to each machine as I connect it to the network by turning on sync. ANybody have any comment or fine tune for me. ?

TheHon · March 29, 2022

On 10/27/2021 at 4:30 AM, Jamieson said:

what I've discovered... On Mac OS anyway…

The files being moved to archive and replaced with zero-byte files still happens every single time I copy files to the synced folder. I now know exactly what is happening;

MacOS creates temporary zero-byte placeholder files when copying files. They’re the little greyed-out ones that show until the actual file is copied to a folder. Resilio sync is quickly syncing those placeholder zero-byte files to computer 2 before the actual files are finished copying to the sync folder locally on computer 1. Since those zero-byte placeholder files have now made it to computer 2 and have a newer timestamp than the actual files, Resilio Sync is determining that they should be kept instead of the actual files, so it is back-syncing those zero-byte files from computer 2 over the actual files on computer 1, and moving the actual files into the archive folder.

The only way to prevent this is to close Resilio Sync completely while copying any files to the sync folder. This way Resilio doesn't have the chance to sync those temporary zero-byte placeholder files in the first place.

Hopefully this can be fixed in an update

This explanation makes a lot of sense, and a fix to address this is pretty simple:

Offer the user to ignore syncing zero-byte files automatically. The few legitimate zero-byte files can be synced manually.
Offer the user a visual confirmation if "newer" zero-byte files are available, while on a different node there are larger files. Allow the user to override the "newer" but zero-byte files manually, and get them marked for syncing again.
Fix timestamp granularity and sync with variable overlap, compensating for network speed (check out how the rsync protocol has been doing this for over 30 years)
Zero Byte files normally are the result of certain operating systems' way of handling copy, or if you touch a file or overwrite a file (log file) with /dev/zero, or if some applications use such files as markers. Make the user select the policy of not automatically syncing zero byte files on a per-directory basis. For example: a picture or documents folder (99% or the cases) does not need zero-byte files, so no auto-syncing of zero-byte files is set. However, if you'd like to sync a log directory, where log files tend to be zero-byte files again, then allow for automatic zero-bytes synchronization by default.

I've just discovered Resilio Sync after I have been seriously disappointed by syncthing (can't fix file mode permission issues after updating to Win11, no matter what I do, and there is no sane way to re-initialize the sync from scratch). I have given Resilo Sync a whirl, and then started going through the forum entries to get myself a picture if this is an active product with a supporting community, and if issues/wishes reported actually get addressed in a transparent, efficient, fast and regular interval. Given that this fundamental issue has been open for such a long time, gives me zero confidence to fork over 100 USD for the product, let alone continue using the freely available version.

Luckily, I've purchased a commercial license from Tresorit (not peer-to-peer, but zero knowledge forward-encrypted, fast and super reliable) for my company, so I can add many users to my setup now. Clearly, it's not the same decentralized p2p technology, but I get my money's worth of support from these guys, and the product is continuously (visibly) extended.

This is very unfortunate, since for private usage I would have liked to use either syncthing or actually Resilio Sync to sync/share personal pictures, movies and documents. Especially since you don't have to limit yourself to some subscription-based storage, or worse, cloud i/o limit.

STILIT · April 15, 2022

We have this exact same issue using Resilio Sync in our video workflow.

When I user copies large media files from an external source on to their workstation and syncs them on our server. The server will then replace the original files after sync on the client side with the Zero Byte placeholders.

Would it be possible to prevent this by setting a Delay Time For Syncing to certain files or in general?
This way the Zero Byte files will not be registered?

MTT · November 29, 2022

Any solution to blocking these 0byte macOS placeholders from becoming the most recent version of a file during a copy?

Sign In

Files Become Zero Byte After Success Upload/Download

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation