Cory Riddell <c...@codeware.com> writes:
> The more I dig, the less certain I am of what's going on.
>
> I made a small program that does what svn_io_remove_file2() does.
>
> Snippet const char* path_to_nonexistent_file =
> "\\\\Diskstation\\svn\\MyRepo\\db\\rev-prop-atomics.shm";
> apr_status_t apr_err = apr_file_remove(path_to_nonexistent_file, NULL);
> TRACE(_T("apr_err = %d\n"), apr_err);
> TRACE(_T("APR_STATUS_IS_ENOENT = %d\n"), APR_STATUS_IS_ENOENT(apr_err));
>
> apr_status_t status = apr_file_attrs_set(path_to_nonexistent_file,
> 0,
> APR_FILE_ATTR_READONLY,
> 0);
> TRACE(_T("status = %d\n"), status);
>
> apr_err = apr_file_remove(path_to_nonexistent_file, NULL);
> TRACE(_T("apr_err = %d\n"), apr_err);
> TRACE(_T("APR_STATUS_IS_ENOENT = %d\n"), APR_STATUS_IS_ENOENT(apr_err));
>
> And the output is:
>
> apr_err = 720005
> APR_STATUS_IS_ENOENT = 0
> status = 720002
> apr_err = 720002
> APR_STATUS_IS_ENOENT = 1
Thank you very much for your efforts. Could you please post a trace for a
non-existing path, but not for the one ending with rev-prop-atomics.shm?
Try "\MyRepo\db\should-not-ever-exist" and maybe "\MyRepo\this-one-too".
I cannot see a reason for rev-prop-atomics.shm to be created in the hotcopy
destination, but this file has some history and we do have a particularly
related change in 1.8.11 (r1543594 and others). So, this is just to be sure
we are not missing something here.
Given the strange behavior with an ERROR_ACCESS_DENIED followed by the
ERROR_FILE_NOT_FOUND, personally, I would be also interested in seeing
the Process Monitor [2] logs for this operation.
[1] http://svn.apache.org/repos/asf/subversion/tags/1.8.11/CHANGES
[2] http://technet.microsoft.com/en-us/sysinternals/bb896645
Regards,
Evgeny Kotkov
