rsync - Apr 2005 - the second time rsyncing a readonly file

Like nifteaux (nifto) man, all I did was change the sleep time and I
get different results:

$ touch u; sleep 0;touch v; chmod 0 v; rsync u v; ls -og u v; /bin/rm -f u v
-rw-r--r--  1 0 2005-04-25 00:05 u
----------  1 0 2005-04-25 00:05 v
$ touch u; sleep 1;touch v; chmod 0 v; rsync u v; ls -og u v; /bin/rm -f u v
-rw-r--r--  1 0 2005-04-25 00:05 u
-rw-r--r--  1 0 2005-04-25 00:05 v

OK, never mind that. What bothers me is

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)

  -r-xr-xr-x  1 jidanni 4248 2005-04-18 03:31 freedom_en.html

Therefore in the manual at
       -p, --perms
              This  option  causes rsync to set the destination permissions to
              be the same as the source permissions.

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. Duh.

One sees a --force, but the docs say it is for other purposes.
I used rsync -a --inplace -v webtree /mnt/usb/cf

-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.

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..