The Samba-Bugzilla – Bug 6025
0 files to consider should not return code 23
Last modified: 2009-01-12 18:49:48 UTC
When rsync is asked to download files and the result is CORRECTLY "0 files to consider", either because the directory just happens to be empty at the moment or the files matching the pattern are CORRECTLY not present in the directory, it returns a CODE 23. This is wrong.
This behavior is incorrect, CODE 23 means "Partial transfer due to error". In such a case there was CORRECTLY nothing to transfer, therefore, the program should exit gracefully with a CODE 0 "Success". Since it has nothing to do and therefore it did nothing.
Returning CODE 23 is missleading for other programmers using rsync inside a shell script as is leads them to believe that there were some actual files to download but for some reason rsync was unable to download them.
In my case, as an example i am downloadig Apache log files from a test server this files are sometimes rotated automatically by cron or sometimes manually deleted.
When I have rsync download all the log files in the usual Apache log directory /var/log/httpd , and the directory just happens to be empty:
rsync -qPt -e ssh email@example.com:/var/log/httpd/access_log.* /root/myoldLogs/
rsync: link_stat "/var/log/httpd/access_log.*" failed: No such file or directory (2)
rsync error: some files could not be transferred (code 23) at main.c(1385)
IMO: "some files could not be transferred" is incorrect as there were no files no transfer.
Note that removing the --verbose option or adding the --quiet option did not solve the problem.
I have seen some people using a workaround by adding a single file using the "touch" command to create a single empty file that would match the pattern on the rsync command, so that "0 files to consider" would be "1 files to consider" and rsync returns CODE 0 "Success".
Pablo Angel Rendon
Rsync is following traditional shell behavior, under which a wildcard pattern that matches nothing is left unexpanded. (Actually, in your case, rsync relies on the remote shell to handle the wildcard, but rsync emulates the same behavior when --protect-args is on.) Thus, rsync tries to copy the file "/var/log/httpd/access_log.*" with an asterisk in the name, which does not exist, hence the code 23. You'll get the same result with cp. This is reasonable because an unmatched pattern is often a mistake rather than a genuine attempt to match zero files.
I suggest that you specify the containing directory as the source and use filters to exclude all the files except the ones you want:
rsync -qPtdO -e ssh --include='access_log.*' --exclude='*' firstname.lastname@example.org:/var/log/httpd/ /root/myoldLogs/
This will successfully do nothing if there are no matching files.
If you don't like including the containing directory in the file list, you could do this instead:
rsync -qPt -e ssh --rsync-path='rsync --files-from=<(find /var/log/httpd/ -maxdepth 1 -name "access_log.*" -printf "%P\n")' email@example.com:/var/log/httpd/ /root/myoldLogs/