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

Re: Windows build severly broken due to read-only issues...

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-02-11 00:18:58 CET

"Jay Freeman \(saurik\)" <saurik@saurik.com> writes:

> OK, is there any complaint about implementing a function (for now let's
> call it svn_io_set_file_write_also()...) that, given a file, removes the
> read-only flag using the implementation of apr_file_attrs_set() I
> provided the APR people (wonder how long it will be before someone looks
> at it...). Then, we call that in close_adm_file() before
> apr_file_rename()? If not, when the Subversion repository starts
> working again (I'm getting the REPORT status 500 error, which makes it
> difficult to test anything, hehe), I'll write the required changes. I
> think that will be sufficient (if not optimal).

Sounds good to me. Depending on what happens to apr_file_copy it may
be that Unix also needs to make the destination writeable before
copying. Will you check for the file's existance before setting the

How about svn_io_set_file_writeable, or svn_io_set_file_read_write for
the name? I'm sort of assuming that Subversion will never want to make
a file unreadable.

> *searches through back archives for this thread Philip mentions*
> OK, I take it that means I'd be completing this little back-and-forth:
> =======================================================================
> Greg Stein <gstein@lyra.org> writes:
> > (btw, for completeness, we'd also want ways to turn off readonly and
> > to the executable state)
> Agreed, it's just I have much less interest in writing those :-)

I subsequently did write and post an APR patch to do this on Unix, see

> --
> Philip
> =======================================================================
> *debates making this a reply to the other thread* *decides against that
> as it may not have as strong an association with this thread*
> I agree with the previous comments by Branko and Karl from the Issue
> #532 thread that more thought needs to go into how this interface should
> be designed, however.

Fine, I have no problem with that. I just hope there are more
contributions than last time ;-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:06 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.