[Bug 13656] New: --link-dest target with symbolic links from different user produces unnecessary error

samba-bugs at samba.org samba-bugs at samba.org
Tue Oct 16 21:48:03 UTC 2018


            Bug ID: 13656
           Summary: --link-dest target with symbolic links from different
                    user produces unnecessary error
           Product: rsync
           Version: 3.1.3
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: Nathan.Gass at localsearch.ch
        QA Contact: rsync-qa at samba.org

Created attachment 14531
  --> https://bugzilla.samba.org/attachment.cgi?id=14531&action=edit
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.

You are receiving this mail because:
You are the QA Contact for the bug.

More information about the rsync mailing list