When copying files from directory A
to B
with rsync
using
$ rsync -a --backup --suffix=.$(date +"%Y%m%d%H%M%S") A/ B/
a file called filename
in A
will temporarily be called something on the form .filename.9Tcfsa
in B
while being transferred. That is, rsync
adds some random characters to the name until the transfer is complete.
If I interrupt rsync
with Ctrl+c while transferring filename
, the temporary file .filename.9Tcfsa
is left in B
. Since my rsync
command never removes any files from B
, each interruption of rsync
will leave another temporary file in B
. This becomes annoying litter.
Is it possible to stop rsync
and have it also removing the temporary file?
UPDATE:
Since other people seem not to experience the issue above, I am providing a script with output to demonstrate what I see on my machine.
Script rsynctest.sh
:
#/!bin/bash
mkdir -p A
mkdir -p B
echo "Creating a 1 GB file in A..."
dd if=/dev/zero of=A/bigfile bs=1M count=1000 >& /dev/null
echo "Now press CTRL-C to interrupt rsync."
rsync -a --backup --suffix=.$(date +"%Y%m%d%H%M%S") A/ B/
Output when running the script twice:
$ ./rsynctest.sh
Creating a 1 GB file in A...
Now press CTRL-C to interrupt rsync.
^Crsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(632) [sender=3.1.0]
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at io.c(521) [generator=3.1.0]
$ ./rsynctest.sh
Creating a 1 GB file in A...
Now press CTRL-C to interrupt rsync.
^Crsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(632) [sender=3.1.0]
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at io.c(521) [generator=3.1.0]
$ ls -a B
. .. .bigfile.KvDV0T .bigfile.MbalWJ
$
Notice that the last ls
command reveals that B
contains two temporary files.
Best Answer
Answer: It's a bug in
rsync
3.1.0.This is a note from the 3.1.1. release notes,
Upgrade your version of
rsync
.Previous stuff
I've just tested this on my system.
So not quite the same version of
rsync
, but the same major version.As expected, when I hit Ctrl+c,
rsync
tidies up and does not leave any temporary files behind.I created
A/
andB/
, filledA/
with some files, and then ranrsync
once to populateB/
. I then just rantouch
inA/
and ran thersync
again.I added a
-v
so I could see which file it was working on, but the behaviour was the same without the -v.No temporary files. So, maybe because the contents haven't changed,
rsync
doesn't need to create a temporary file.This time, I have a single big file in
A\
.I sync
B/
Then, completely replace
bigfile.tgz
with something else.That's a different tgz archive just copied over and over to make up the same file size.
No temporary file.
Starting again, new file.
Sync to
B/
Now, recreate
A/bigfile.tgz
with different content,This time, run the
rsync
with--partial
and see what changes. That switch is the one which usually forcesrsync
to leave partial files behind rather than clearing them up.As we can, this time,
rsync
has created a temporary file (called bigfile.tgz) with the old one already given the new extension.Edit: one set of tests again using
ls -la
.So
B/
is synced,Replace
A/bigfile.tgz
and resync.No temporary file.
I can't recreate the behaviour you describe using basic
rsync
.Are you sure your
rsync
command is exactly as described, and are you sure it's not aliased somewhere to be something else?Update:
Using your script, on a different machine,
Another machine, this time Ubuntu rather than pure Debian.