rsync - Jun 2003 - --link-dest when target and compare_dir both have file

Hi J.W. et al,

Kevin Everets was kind enough to inform me about some strange behavior in
his backup script, which seems to be the result of --link-dest behaving 
unexpectedly in the case where target/ is already populated with older 
versions of the same file.

Here's the situation:

We want to do:
$ rsync -a --link-dest=../backup.1 source/ backup.0/

There is a file present under all three directories.  Suppose that it the
version in backup.1/ is identical to the version in source/, and that
backup.0/ contains an older version.

In this case, I would expect:
1. the version in backup.0 should be unlinked
2. a new hard link should be created in backup.0/ to the copy in backup.1/

In fact, rsync (at least as of 2.5.6) seems to copy the full file:

------------------------------------------------------------------------
(blank lines added for readability)
------------------------------------------------------------------------
$ rsync --version
rsync  version 2.5.6  protocol version 26
Copyright (C) 1996-2002 by Andrew Tridgell and others
<http://rsync.samba.org/>
Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, 
              IPv6, 64-bit system inums, 64-bit internal inums

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.

$ mkdir source
$ touch source/a
$ touch source/b
$ rsync -a source/ backup.0/

$ # Wait a minute or so.

$ touch source/a
$ rsync -a source/ backup.1/

$ # Now backup.1 has the newer version of a, and backup.0 has the original 
$ # version; this would normally be the state after the rotation.  Wait 
$ # another minute or so.

$ touch source/b

$ # this updates the timestamp on source/b

$ ls -l *
backup.0:
total 0
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:57 a
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:58 b

backup.1:
total 0
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:58 a
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:58 b

source:
total 0
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:58 a
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:59 b

$ # Now, we think this should only transfer b, because the most recent
$ # version of a is already in backup.1; it should link-dest a...

$ rsync -avv --link-dest=../backup.1/ source/ backup.0/
expand file_list to 4000 bytes, did move
done
delta-transmission disabled for local transfer or --whole-file
a
b
total: matches=0  tag_hits=0  false_alarms=0 data=0
wrote 168 bytes  read 52 bytes  440.00 bytes/sec
total size is 0  speedup is 0.00

$ ls -i backup.0 backup.1
backup.0:
  87905 a    87900 b

backup.1:
  87903 a    87904 b

------------------------------------------------------------------------

So... b seems to have been copied as a whole from source/, even though there
was already an identical version of it already in backup.1.

Would you say this a bug, feature, or (most likely, based on my experience),
a case of me being a doofus and not understanding how it's supposed to work?

This becomes an issue when using the directory reuse suggested to me by
J. Pelan in combination with --link-dest.

Thanks,
Mike

Hi J.W. et al,

Kevin Everets was kind enough to inform me about some strange behavior in
his backup script, which seems to be the result of --link-dest behaving 
unexpectedly in the case where target/ is already populated with older 
versions of the same file.

Here's the situation:

We want to do:
$ rsync -a --link-dest=../backup.1 source/ backup.0/

There is a file present under all three directories.  Suppose that it the
version in backup.1/ is identical to the version in source/, and that
backup.0/ contains an older version.

In this case, I would expect:
1. the version in backup.0 should be unlinked
2. a new hard link should be created in backup.0/ to the copy in backup.1/

In fact, rsync (at least as of 2.5.6) seems to copy the full file:

------------------------------------------------------------------------
(blank lines added for readability)
------------------------------------------------------------------------
$ rsync --version
rsync  version 2.5.6  protocol version 26
Copyright (C) 1996-2002 by Andrew Tridgell and others
<http://rsync.samba.org/>
Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, 
              IPv6, 64-bit system inums, 64-bit internal inums

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.

$ mkdir source
$ touch source/a
$ touch source/b
$ rsync -a source/ backup.0/

$ # Wait a minute or so.

$ touch source/a
$ rsync -a source/ backup.1/

$ # Now backup.1 has the newer version of a, and backup.0 has the original 
$ # version; this would normally be the state after the rotation.  Wait 
$ # another minute or so.

$ touch source/b

$ # this updates the timestamp on source/b

$ ls -l *
backup.0:
total 0
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:57 a
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:58 b

backup.1:
total 0
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:58 a
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:58 b

source:
total 0
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:58 a
-rw-rw-r--    1 mrubel   mrubel          0 Jun  1 18:59 b

$ # Now, we think this should only transfer b, because the most recent
$ # version of a is already in backup.1; it should link-dest a...

$ rsync -avv --link-dest=../backup.1/ source/ backup.0/
expand file_list to 4000 bytes, did move
done
delta-transmission disabled for local transfer or --whole-file
a
b
total: matches=0  tag_hits=0  false_alarms=0 data=0
wrote 168 bytes  read 52 bytes  440.00 bytes/sec
total size is 0  speedup is 0.00

$ ls -i backup.0 backup.1
backup.0:
  87905 a    87900 b

backup.1:
  87903 a    87904 b

------------------------------------------------------------------------

So... b seems to have been copied as a whole from source/, even though there
was already an identical version of it already in backup.1.

Would you say this a bug, feature, or (most likely, based on my experience),
a case of me being a doofus and not understanding how it's supposed to work?

This becomes an issue when using the directory reuse suggested to me by
J. Pelan in combination with --link-dest.

Thanks,
Mike