Bug 6095 - code 23 when files or directories disappear, instead of code 24.
code 23 when files or directories disappear, instead of code 24.
Product: rsync
Classification: Unclassified
Component: core
x64 Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2009-02-06 11:42 UTC by Ken Moffat
Modified: 2009-02-14 10:39 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ken Moffat 2009-02-06 11:42:24 UTC
I use a wrapper script to rsync to an nfs share.  This runs from an fcrontab, so it is not unusual for files to be deleted while the script is running, for example if I remove a source directory after compiling it.  The wrapper handles code 24 and the process is regarded as successful.

 Since 3.0.4 I'm sometimes seeing code 23 in this situation. The manual suggests that is a real error. I first saw it with 3.0.4 on x86_64, and initially assumed the error code had changed - until a run earlier this week gave me the previously expected code 24.

 Google has a number of postings for rsync code 23, all but one were from 3.0.4, the other was from 3.0.2.  Most of them are just logs.

 Yesterday, I updated to 3.0.5 on x86 and tested.  The command is rsync -aHx --delete --numeric-ids /home /nfs/staging/ .  By untarring a package, starting the wrapper, then deleting the package 2 or 3 seconds later, I got:
Thu Feb  5 22:35:23 GMT 2009 rsyncing
rsync: link_stat "/home/ken/abiword-extras-2.6.6" failed: No such file or directory (2)
IO error encountered -- skipping file deletion

 Today, I've repeated this adding -vvv to the command. The wrapper ended with
sent 70132491 bytes  received 810694 bytes  287801.97 bytes/sec
total size is 13287948825  speedup is 187.30
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1040) [sender=3.0.5]
_exit_cleanup(code=23, file=main.c, line=1040): about to call exit(23)

 but within the approx 100MB of output, the only thing I found which looked like an error was:
rsync: link_stat "/home/ken/abiword-extras-2.6.6" failed: No such file or directory (2)

 I'm starting to think that perhaps this is caused by a missing directory, and/or there might be a race (because sometimes it seems to work as expected).
The affected systems were using kernels 2.6.28 and, with gcc-4.3.2 and 4.3.3 and glibc-2.8 or 2.9.
Comment 1 Wayne Davison 2009-02-14 10:39:07 UTC
I believe you are correct that this is caused by a vanishing directory.  The code interpreting some link_stat() failures was changed in a recent release, and it looks like your use of -x caused the stat() of a vanished directory to cause an error 23 when it should have checked for ENOENT and handled it as a vanished file.  I've checked in a fix for this.  Thanks for the report!