On 1/21/2015 3:00 PM, Philip Martin wrote: > "Bert Huijben" <b...@qqmail.nl> 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