On 1/21/2015 3:00 PM, Philip Martin wrote:
> "Bert Huijben" <[email protected]> writes:
>
>>> Windows code is tricky. When svn_io_remove_file2() gets EACCES it calls
>> For something to return access denied on Windows it must exist.
> Yes, the file exists when we try to remove it.
>
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
If I run the program a second time, I get the same output again.
So, the first error is a EACCESS, then the non-existent file is made
writable, then a ENOENT error is generated.
It doesn't make sense to me, but I think the bottom line is that the
second apr_file_remove call can generate an ENOENT result and if the
ignore_enoent parameter is TRUE, then the function should return
SVN_NO_ERROR after the second (or third) try.
Cory
