Does rsync need a --ignore-unreadable-files option?
kmk at sanitarium.net
Thu Jan 10 19:13:44 MST 2013
-----BEGIN PGP SIGNED MESSAGE-----
I am not really sure what you are requesting here. Rsync does
continue after it encounters a permission denied error. It just can't
copy that particular file/directory but it will continue on through
The reason for the second error message and the exit 23 is to inform
you that there was a problem (if you are running with -v the rest of
the tree can easily scroll the real error off the screen).
When such an error is encountered --delete will stop deleting stuff
unless you use --ignore-errors but rsync will finish copying what it can.
On 01/10/13 21:07, Allen Supynuk wrote:
> I work on software that archives gigabytes of files to multiple
> Occasionally one or two files have no read permissions:
> % ls -l dir/foo --w-------+ 1 abcserve myusers 11222 Jan 10 03:14
> The error message is: rsync: send_files failed to open "/dir/foo"
> (in xxx): Permission denied (13)
> rsync error: some files/attrs were not transferred (see previous
> errors) (code 23) at main.c(1518) [generator=3.0.9]
> To make matters worse, the file is on a read-only snapshot mounted
> through NFS. In any case root squash is in effect, so super-user
> is out.
> I fully realize that the correct answer is "fix the file
> permissions and regenerate". Which is precisely what we do today.
> However, regenerating takes several hours, so no one has access to
> the archives until it is done.
> The one work-around I have found is to redo the rsync with
> --exclude='/dir/foo'. I am thinking about adding a facility to my
> software that generates the rsync commands to allow adding
> It strikes me though, that what I really want is an rsync option
> '--ignore-files-with-no-read-perms'. This rightfully should be off
> by default, but once you have a system up and running like we do,
> it says "if we screw up the read permissions on an occasional file
> just keep going". I would expect that '--itemize-changes' would
> make a note that the file was not copied.
> In my case, the files have always had no read access for anyone,
> and are owned by id running rsync. That is, if the files *were* on
> a writable volume, chmod.would fix it (but not --fake-super, nor
> any combination of --no-perms and --chmod=ugo+r that I tried on
> /tmp on my desktop). That is, there is no possibility of anyone
> other than someone with root access to the file system making a
> copy of this file. Having an option to ignore seems safe enough.
> Ignoring return code 23 (Partial transfer due to error), similar
> to the FAQ suggestion for code 24 (Partial transfer due to
> vanished source files) seems much too risky. I only want to ignore
> the case of the files being unreadable because they were explicitly
> denied read permissions, not because of media failure or (my
> favorite vendor response) "ionizing radiation".
> Am I missing some obvious settings that can achieve this? An hour
> spent googling, reading the rsync posts on Stack Overflow, and the
> last 14 months of archives on this list found nothing.
> Ps. If this does make sense I am volunteering to make the change.
Kevin Korb Phone: (407) 252-6853
Systems Administrator Internet:
FutureQuest, Inc. Kevin at FutureQuest.net (work)
Orlando, Florida kmk at sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the rsync