Philip Martin <philip.mar...@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
