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 (...));
>> }
>> }
>>#endif
>>
>>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
implementation).
> 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