On 11/14/05, Branko Čibej <brane@xbc.nu> wrote:
> Erik Huelsmann wrote:
> >> This behavior was added in r14304 by Brane for fix issue #2278. I
> >> understand for what we clear destinition file's read-only.
> >> On Linux mv doesn't preserves destination permisions, why we have
> >> different behavior on Windows?
> >>
> >
> > To jump in:
> >
> > On unix, you can rename over a read-only file. The *source*
> > permissions in this operation are preserved (and -ofcourse- attached
> > to the destination after the rename).
> >
> First let me point out that there is a big difference between the
> read-only flag and file permissions on Windows.
>
> As far as I can remember, this change was made in order to preserve
> svn:needs-lock semantics during update in the Windows working copy. It's
> possible that it would work just as well if was_read_only was read off
> the source, not the target; I certainly wouldn't want to blindly change
> things.
> I think that, if you trace back through the update sequence, you'll find
> that when replacing a file's contents in the working copy, the temporary
> file (i.e., before svn_io_file_rename is called) will have the same
> read-only state as the target file.
On unix, we set the read-only property after moving the file into
place. Also, the source doesn't have the read-only state - neither on
windows nor on unix. That's due to the fact that every translated file
is recreated from scratch (on windows that means w/o readonly attr).
So, I suppose I should be testing trunk on a windows box and see what
happens if I change svn_io_file_rename...
Thanks for the info!
bye,
Erik.
Received on Tue Nov 15 00:03:25 2005