RClone acts as if files in VSS snapshots change during copy

Help and Support
1

What is the problem you are having with rclone?

When syncing from a VSS snapshot, files still fail to be copied due to the following error:

Failed to copy: can't copy - source file is being updated (size changed from 0 to 1073)
Removing partially written file on error: can't copy - source file is being updated (size changed from 0 to 1073)

The easiest way to reproduce this is by trying to back up a Chromium profile while Chromium is running.

I'd like to understand why this is happening. VSS snapshots should be fixed in time, but RClone acts like the file sizes change during the copy. How is this possible?

Steps to reproduce

  1. Create a volume snapshot, e.g. via vshadow.exe or vscsc.exe
  2. Run Chromium
  3. Try to back up the Chromium profile via (a symlinked) snapshot rclone sync d:\.snapshot f:
  4. See errors

When using set rclone_local_no_check_updated=true this error is gone.

What is your rclone version (output from rclone version)

rclone v1.54.0

  • os/arch: windows/amd64
  • go version: go1.15.7

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Windows 10 x64

Which cloud storage system are you using? (eg Google Drive)

Local and WebDAV

2

What that means is that when rclone listed the directory it got a size of 0 for the file. When it comes to transfer the file it stats the file and gets a size of 1073 and then is confused!

@asdffdsa you know lots about VSS snapshots - any ideas what is going on here?

3

hello and welcome to the forum,

i have no idea what is going on, as you would need to post all the needed info from the rclone help template, the script used to invoke VSS and the script used to backup chromium.

i use VSS+rclone, 10,000+ times on multiple computers and servers on a daily basis
on that VSS snapshot, i run veeam, 7zip, fastcopy and rclone.

i have a wiki about VSS+rclone, perhaps that can help.
there is a simple four line script, i suggest you get that working and tested first.
https://github.com/rclone/rclone/wiki/How-to-enable-VSS-for-rclone

tl;dr - do not trust VSS to backup the data of a running app.

i would not trust VSS to backup the data of a running app unless that app has explicit support such as sql server or exchange server.
VSS relies on the app to put itself into a known state, save config files, flush files to disk, process pending database transactions and so on.

to backup an app, for example, i use firefox, i do the following

  1. create VSS snapshot
  2. backup up the firefox profile folder
  3. delete the VSS snapshot.
  4. then run firefox

or get the app itself to call a backup script.
for example, i depend on keepass.
i have a trigger, each time the database is changed, it is saved and each time the database is saved, keepass calls a script. it is the script that will create a VSS snapshot and backup the keepass database file.
in that way, i know that the keepass database is flushed to disk, no open file handles and is in a self-consistent state.

4

Ugh, I can't upload files or post links, so here's the script I made: bin.disroot.org/?99cc7f41dd8c548e#3E44QT2dKU8UqW24dYCSbwWJmAUsffUuu8rwVCLkDqDN
I'll post a log with log level DEBUG later today.

@asdffdsa Programs of which I absolutely want to be sure of that their data aren't corrupted in the backup, I close, no doubt. Most of the files that fail this way are either log and session files, such as:

/Default/Extension State/000003.log
/Default/Extension State/LOG
/Default/Sessions/Session_13256919047692
/Default/Sessions/Tabs_13256919047900946
5

our approaches are very different.
i have a python script that generates, on the fly, the .cmd batch files and then runs the .cmd.
uses a microsoft written and supported app, vshadow.exe that works on windows 10 and window server 2019.
as i mentioned, it works with rclone, as well as 7zip and fastcopy.

as for your approach, it seems to use vscsc.exe, a third party tool.
when i was creating my solution, i did visit that website, it was clear to me that it was going to be my solution.

  • when i tried to visit the website, vscsc.sourceforge.net, i got a scary message that the website is not secure.
  • last update was 2013-04-29
  • no forum posts since 2018
  • that site has not tested vscsc.exe on windows 8,10, window server 2012, 2016, 2019
  • that site makes a false claim
    "Unfortunately there in no application that can give you the advantage of shadow copies if you are using a script for backing up your data"
  • it recommends robocopy, which is a no go for me, as it cannot compare checksums of copied files, i use fastcopy

my advice, if you want to use that software:
create a script that uses the command line copy command, not rclone.
once that is working, then test with rclone

6

Thanks for looking into it.

Sourceforge itself is just a bitch of a website, after they got taken over. They have been known to bundle adware with software releases in the past, which is probably why you got the message (if it was because of your antivirus software or browser's protection, otherwise it was perhaps just a certificate error perhaps?). Doesn't say anything about the tool itself.

I've been using vshadow.exe as well, it's just not as friendly with scripts imho, and the snapshots created by vscsc.exe are just fine. I believe I had the exact same issues with vshadow.exe, but I'll retry with that tool for completeness' sake.

create a script that uses the command line copy command, not rclone.
once that is working, then test with rclone

As said, it does work with RClone, as long as I set rclone_local_no_check_updated=true.

8

This is a debug log using vscsc.exe (cleaned lines with successful operations):
https://bin.disroot.org/?278a5717767b01c0#FBzDw8UcFj47RPq6vTPiS7bPxNp7LLLhwAgiSNACUDMc
This is a debug log using vshadow.exe (no differences as far as I can see):
https://bin.disroot.org/?e65bd7d3a7bba572#2ZunnAwZZJJPALgQVPzgy2shHz3bmHBP5mbgr7dvv8J7

When using a remote destination, the error messages differ somewhat:
https://bin.disroot.org/?d32681a71c0a8fb8#7ytsLik6vvwTVhsJ1HGa3YMXMhgnhexezKUh7N1CFzBN

9

i would test with an app other than rclone and see what happens.

10

With other programs? Copying works. I tried using Explorer, Total Commander and copy for a few of the listed files.

I did get my answer there, though... All of those applications show a file size of 0 bytes for the affected files, but after being copied (successfully every time), they turn out to be fine. (This was while using vshadow.exe.)

It should be noted that copying these files from the original non-VSS location poses no problems whatsoever (they're in use, but they aren't locked). They also show 0 bytes on their original location, until copied elsewhere.

So, apparently there's an oddity in VSS and RClone's way of working picks up this oddity and as a result fails to copy files where it doesn't have to fail.

11

how do you know that, with 1000% confidence, by what metric, not by size?

seems to me, the real issue is not copying the file, but the confidence that when needed, at some future date, that the copied file is not corrupt and can be used for a recovery of data.

that problem still remains, that the file is in-use, unknown to be in a self-consistent date.
many browser files and other apps, are sql databases.

without that confidence, i will continue to backup an app's data before starting that app.
for which VSS is not needed.

12

I see your point and of course it's better to do so. My point of this topic was above all to understand what was going on and if RClone was handling these errors in the right way.

Apart from the latter, I think it is really strange that a snapshot has those files presented with a size of 0, while that's not the case when copied. I can understand that when copying from the actual source, as those files are in use by the Chromium processes, but not from the snapshot.

As for RClone's handling, I didn't know when I started the topic that these files are actually listed with file size 0 (or in some cases 8 bytes) in the snapshot. That's why I wanted to know more about this behavior.

13

i agree, this is all very interesting.

i only wrote what i did, as we get many newbies here.
that you might be a newbie, but now i see that is not the case.
that they would think that the VSS copy of a open file is in fact a backup.

1 Like
14

No it makes sense of course to make sure the snapshot is created before programs are started, if you really need to use them while backing up. I just couldn't get my head around these error messages by RClone, but apparently the snapshot shows these files with other file sizes (0 or 8 bytes, as far as I've seen), just like the in-use files are shown on the original filesystem.

@ncw

  1. As such, I suppose it can be useful that RClone warns you of these files, but I'm not sure that RClone should fail to copy them completely.
  2. Also, I'm not sure why RClone's retries are actually retries of all files and not just the failed ones (I believe I have seen another topic about this in the past).
15

There isn't much rclone can do here. A file was being copied. It was closed when it started. It was opened and changed so when something reads to it, it needs to know the file changed and it would fail.

It only retries failed items.

16

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.