Open nahuel opened 3 years ago
I'm adding a warning about this to the man page for now, as suggested. In the future I will consider having the receiving side back-date an interrupted in-place file to an mtime slightly less than the source file's mtime, and probably only if --update
was used.
Suppose you have a file in
hostA
:You download it from
hostB
using:If the transfer is aborted,
hostB
will get only a partial file:BUT the
ctime/mtime
ofhostB/test.txt
now is NEWER thanhostA/test.txt
(andmtime == ctime
). So, if you run the samersync -u
command again:Rsync will SKIP THE FILE, because
hostB/test.txt
is "newer" thanhostA/test.txt
. So you CAN'T resume usingrsync -u
command, and you will think there are no differences.Note this is really need because there are scenarios where checksum comparison can't be used, only comparison by time. For example, to avoid deleting changes made in
hostB
totest.txt
. Also I need to use--inplace
.A reproducible test:
To avoid this bug,
rsync
must create the file withctime=mtime=0
. And if the file already exists before transfer,rsync -u
must not change his currentctime/mtime
. The values ofctime/mtime
must be updated ONLY after the transfer was successfully completed. But researching more, I see POSIX has NO way to disablemtime
updating while callingwrite()
's, so there is no way to atomically leave a partial file with anmtime=0
mark while using--inplace
.rsync --update --partial
(no--inplace
flag) can do it because it transfers first to a temporal file, then updates hismtime
(to 0 if unsuccessful, or to the original filemtime
if transfer completed), and thenrename()
s the file.So I think this can't be solved, but a warning should be placed in the rsync manpage/CLI about this
-u --partial
unexpected behavior.