Bug 8246 - rsync hangs with --hard-links and unreadable files
rsync hangs with --hard-links and unreadable files
Product: rsync
Classification: Unclassified
Component: core
All Linux
: P5 minor
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2011-06-19 16:20 UTC by Chris Dennis
Modified: 2011-07-04 23:09 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dennis 2011-06-19 16:20:58 UTC
I've stumbled across a fairly obscure situation in which rsync hangs -- it just waits until I press ctrl-C.

Here's a transcript.  Note that directory 'foo' contains two small files that are hard-linked together, and have no read permission.  

$ uname -a
Linux ferox 2.6.35-28-generic-pae #50-Ubuntu SMP Fri Mar 18 20:43:15 UTC 2011 i686 GNU/Linux
$ rsync --version
rsync  version 3.0.7  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

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.
$ ls -dl foo
drwxr-xr-x 2 chris chris 4096 2011-06-09 23:23 foo
$ ls -il foo
total 8
15958048 --w------- 2 chris chris 193 2011-05-25 19:19 bd
15958048 --w------- 2 chris chris 193 2011-05-25 19:19 bd2
$ rsync -avv --hard-links foo /tmp
sending incremental file list
delta-transmission disabled for local transfer or --whole-file
rsync: send_files failed to open "/home/chris/Dropbox/perlwork/brandysnap/foo/bd2": Permission denied (13)
^Crsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(543) [sender=3.0.7]

The hang doesn't happen if --hard-links is not specified, or the files have read permission.
Comment 1 Wayne Davison 2011-07-04 23:09:38 UTC
Interesting.  When the generator receives FES_NO_SEND from the sender (through the receiver), it is not noticing that the failed file is the leader for a hard-linked set, and thus it is not ever getting back to the first file in the set to (try to) finish it up.  Thus, it hangs forever waiting for something to decrement the in_progress count on the file's file-list.

I've checked in a fix for this.