the second time rsyncing a readonly file

[Wayne Davison]

On Mon, Apr 25, 2005 at 12:37:11AM +0800, Dan Jacobson wrote:
> all I did was change the sleep time and I get different results:

The change in the sleep time caused the files to get either the same
modtime (sleep 0) or a different modtime (sleep 1), and thus affected
whether rsync actually updated the file or not.

> rsync: open "/mnt/usb/cf/webtree/media/ham/freq/freedom_en.html"
> failed: Permission denied (13)
> rsync error: some files could not be transferred (code 23) at main.c(702)

Yeah, that can currently happen if the destination file is marked
without read permissions and rsync tries to read it for the checksum
generation.  That needs to be handled better, because the file is still
updated (if --inplace is not used), just no checksums were used during
the update (so the "some files could not be transferred" code is not
accurate).  Also, since the file is being treated as non-existent, the
permissions are set like they would be for a newly-created file (in the
absence of --perms) instead of being inherited from the unreadable
destination file.  This strange behavior has been around for ages, BTW.

> also mention what to do when one copies some readonly files, only to
> find that later we can't update them a second time, because they are
> readonly.

This is only true with --inplace, and the manpage already contains this
warning under that option:

    Also note that rsync will be unable to update a file in-place that
    is not writable by the receiving user.

> -p:       Without this option, each new  file  gets  its  permissions  set
>           based  on  the  source  file's  permissions and the umask at the
>           receiving end,
> 
> Added?, subtracted?, etc. Say so.

The normal way the umask works:  perms & umask.  I'll consider changing
the "and the umask" phrase to "masked with the umask value".

..wayne..