OK, the patch I sent a few hours ago definitely helps, but the problem
still exists. Another way to hit it is to "svn add" a directory and
then "svn remove" it. You get:
apr_error: #22505, src_err 0 : <Access is denied. >
error removing administrative directory for private
The problem here is that the code is calling
apr_dir_remove_recursively() to remove the .svn directory.
Unfortunately, there are read-only files in there, so that isn't going
to work. Now, svn_io_set_file_read_write() just isn't going to cut the
butter in this situation. We could add another function that
recursively walks to the directory structure using APR and runs
svn_io_set_file_read_write() on every file and directory it comes
across, but I can't imagine that would be a "good" way to solve this
I'm starting to think that this is more of an APR issue, and we should
get APR to add "force" flags to the various APR file_io functions.
However, as the usage of that force flag will likely have slightly
different meanings on different platforms (such as here, where you
wouldn't need force to remove a read-only file on Unix), it might seem
very un-cross platform.
Does anyone else have any suggestions? What was the reasoning behind
setting these files to be read-only in the first place? It seems like a
bad idea to me. It isn't as if you are likely to _accidentally_ open
the file, modify it, and save the contents. It just annoys the people
who know what they are doing :). I've modified plenty of working copies
to point to different CVS servers in the past, and I can imagine
implementing a little program that changes the URLs on a Subversion
working copy, now I would have to un-readonly them and re-readonly them
as well. Also, on Windows, whenever you try to move a working copy or
delete a working copy you get a little "are you SURE you want to delete
such-and-such read only file?".
Could someone explain this to me? Or point me to where the idea first
came up so I can see the purpose?
Jay Freeman (saurik)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 21 14:37:07 2006