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

Re: svn.collab.net is now running Subversion 0.23.

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-05-21 22:36:48 CEST

cmpilato@collab.net wrote:

>Philip Martin <philip@codematters.co.uk> writes:
>>Now when Subversion calls svn_io_file_rename it always expects the
>>rename to succeed, perhaps we should use that knowledge and change
>>svn_io_file_rename to something like
>> status = apr_file_rename (...);
>>#ifdef SVN_WIN32
>> if (status is "Access is denied")
>> {
>> status = apr_file_rename (...); // immediate retry
>> if (status is "Access is denied")
>> {
>> apr_sleep (...); // or some sort of Windows flush or magic
>> SVN_ERR (apr_file_rename (...));
>> }
>> }
>>We can't really do that in APR since it is, in general, perfectly
>>acceptable for apr_file_rename to fail with a permissions problem.
>I dunno about all that, now. APR's job is to provide reliable
>functionality across all platforms. Certainly that task includes
>making up for shortcoming in those areas of operating systems that
>have them.
It's not a shortcoming, it's a fact. And yes, CloseHandle is
asynchronous (internally, that is -- theoretically it should block the
caller, but it's notoriously hard to do that in the filesystem

> I think this is a perfectly reasonable thing to ask of
>APR. If, in fact, there is a real permissions problem, the second
>rename attempt would be allowed to fail with that error.
>You really don't think APR should do this?
No, I think it shouldn't. It's not APR's mandate to provide reliable
functionality; the mission statement reads "consistent if not
identical", so this is quite all right.

What's more, we actually know that there _can't_ be a permission
problem, since we're creating the files oursleves. So yes, something
like this might be appropriate; but I'd rather create a small testcase
and send it to MS. D.J.'s right -- the handle must be in an inconsistent
state in order to get an access deined error, and that state simply
shouldn't be visible to a (user mode) applicaition.

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 21 22:37:14 2003

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.