Bug 13569 - --link-dest may follow symlinks and failure to hard link a non-regular file is fatal
Summary: --link-dest may follow symlinks and failure to hard link a non-regular file i...
Status: NEW
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.3
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2018-08-13 06:33 UTC by Donald
Modified: 2018-08-13 06:33 UTC (History)
0 users

See Also:

script to demonstrate bug (451 bytes, application/x-shellscript)
2018-08-13 06:33 UTC, Donald
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Donald 2018-08-13 06:33:05 UTC
Created attachment 14406 [details]
script to demonstrate bug

With --link-dest the search for a candidate to link from, follows symlinks in directory path components, when the path element is a directory in the source tree but a symlink in the --link-dest tree. This may trigger unwanted side effects (e.g. automounter mounts). Moreover, the target candidate found might not be suitable for a hard link, because it may be on another file system. For regular files, rsync tried so fall back to copy, which might be unwanted (e.g. going over nfs). For non-regular files, rsync will create the destination file, but report an error and exit with a non-zero exit status.

Attachment is a script which demonstrates the bug. Outputs "RSYNC FAILED" on my system.

The second rsync of the scripts fails, because src/dir is a link to another filesystem in the --link-dest tree but a directory in the new src and src/dir/test is a non-regular file.

Happens with 3.0.9 and with the current git master version.

We've seen our rsync based backup triggering automounts on the backup server or fail from time to time, because of the above problem. Users sometimes move directories somewhere else and create a symlink to the new destination in the old place or visa versa. So with incremental backups you do have real files one day and a symlink to the same tree another day.