Philip Martin <philip.martin_at_wandisco.com> writes:
>> In the line "SVN_ERR(svn_io_remove_file2(shm_name, TRUE, pool));", the
>> TRUE parameter is supposed to suppress file not found errors yet that's
>> the error I'm getting, isn't it?
>
> Yes, it should. It's failing because it's getting error 720002 and that
> is not an error the code recognises. I don't recognise it either. What
> sort of network drive is producing that error?
E720002 on Windows means an ERROR_FILE_NOT_FOUND error [1] — that's
2L rebased onto the APR_OS_START_SYSERR (720000).
I did a quick peek into the svn_io_remove_file2() function. The fact that
we are receiving the error means that we are getting it from one of the two
apr_file_remove() calls. That's either after an attempt to remove a readonly
attribute or from a retry loop.
The reason why this error is propagated up the stack is that we only examine
the 'ignore_enoent' argument after the first apr_file_remove() call. This is
racy — if we get a EACCES during the first attempt to remove a file, and the
file is simultaneously removed from the disk, the next attempt to remove it
would fail with a ENOENT, even with 'ignore_enoent'. I think we should
fix this by suppressing ENOENTs from every apr_file_remove() call, not
just the first one.
I am not sure about the reason why we are receiving an EACCES for the
/db/rev-prop-atomics.shm in the destination filesystem. Hotcopy is
non-incremental, and revprop caching got disabled in 1.8.11, so the file
should not be in the destination. Hence an attempt to blow it away with
the cleanup_revprop_namespace() call should be a no-op (I suspect that we
could completely drop this call, but that's another story). It might be
a NAS-specific behavior, but this is just a random guess.
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382
Regards,
Evgeny Kotkov
Received on 2015-01-21 20:00:22 CET