[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_io_file_rename preserves *destination* file permission on Windows

From: Ivan Zhakov <chemodax_at_gmail.com>
Date: 2005-11-15 23:24:17 CET

On 11/16/05, Branko Čibej <brane@xbc.nu> wrote:
> Ivan Zhakov wrote:
> > On 11/15/05, Erik Huelsmann <ehuels@gmail.com> wrote:
> >
> >>>> All tests pass with no-op svn_wc__prep_file_for_replacement and
> >>>> changed svn_io_file_rename. What do you think about this?
> >>>>
> >>>>
> >>>>
> >>> Please don't even consider ripping that code out before you're 100% sure
> >>> it's not needed (any more). I certainly didn't make those changes for
> >>> fun. They were needed at the time.
> >>>
> >> Oh, I know. I wasn't talking about ripping *all* af it, just the part
> >> where it retains the read-only bit on the destination.
> >>
> >> If I consider that:
> >> - svn:needs-lock was developed on *nix (linux, probably)
> >> - in *nix it's possible to overwrite a read-only file
> >> - unix retains the attributes on the file being renamed
> >> - on Windows a file cannot be renamed if it or its rename-target is read-only
> >>
> > Interesting note: Windows *allow* rename read-only files, but fail if
> > target is read-only. Could anybody fix me? Brane, what do you think?
> >
> Yikes. It looks like this is actually the case. If that's true, we'd
> really only have to (optionally) make the destination read-write, and
> really rip out the rest of the code...
>
> Wait a sec, let me try that. (I still can't remember why I looked at the
> target's read-only-ness... possibly it had something to do with the
> files in .svn, too, although I've no idea what...)
Sorry, I have already commited in r17366. So we need fix something after commit.

--
Ivan Zhakov
Received on Tue Nov 15 23:25:32 2005

This is an archived mail posted to the Subversion Dev mailing list.