[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: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2005-11-15 19:00:56 CET

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
> - svn_io_file_rename should behave the same on all platforms
> I think that the change should not be ripped out, but has a bug: If it
> were to remove the readonly bit on both files and put back
> read-onlyness *of the source* it behaves the same on both *nix and
> windows (instead of the current situation where it does the same
> thing, but uses the target atts).

BTW: Before sending the aforementioned reply, I searched the mailing
list and read the issue: nowhere does it say we need to retain
readonlyness on the target of the rename operation; it *does* say that
you can't rename a readonly file, or even rename another file over a
readonly file.


Received on Tue Nov 15 19:04:21 2005

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