Bug 13656 - --link-dest target with symbolic links from different user produces unnecessary error
Summary: --link-dest target with symbolic links from different user produces unnecessa...
Status: NEW
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.3
Hardware: All Linux
: P5 minor (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2018-10-16 21:48 UTC by Nathan Gass
Modified: 2018-10-16 21:48 UTC (History)
0 users

See Also:

reproducing script (182 bytes, application/x-sh)
2018-10-16 21:48 UTC, Nathan Gass
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Gass 2018-10-16 21:48:03 UTC
Created attachment 14531 [details]
reproducing script

I'm using rsync in a tool which atomically distributes directories by using symbolic links and atomically overwriting them. to still avoid unnecessary extra copies while generating a new directory I use --link-dest.

If I have a symbolic link belonging to a different user in the --link-dest directory, linux does not allow a hardlink on that file. rsync outputs that error and has a return code 23. The resulting copy though is correct, but with the symbolic link copied instead of hardlinked. The only difference between the call with --link-dest and without is the owner of the file, which has to be from the --link-dest directory if provided but is the current user without --link-dest. As I did not explicitly ask to copy owners this are both imho correct results and should therefore not result in a 23 return code.

The attached script reproduces the problem (as written requires root, as we need a symbolic link from a different user). The output I see on my machine is:

$ sh rsynctest.sh 
rsync  version 3.1.3  protocol version 31
Copyright (C) 1996-2018 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes, prealloc, SLP

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.
rsync: failed to hard-link ../src/link with link: Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1189) [sender=3.1.3]

I would have expected at least a different error code, as the directory got copied correctly. Alternatively ignoring that error by default or having an option to ignore it would of course be even more convenient. If the --link-dest option is removed from the script, the rsync copies the directory without error and return code is 0.