Re: Unable to hotcopy to a NAS shared directory: E720002

On 1/21/2015 3:00 PM, Philip Martin wrote:
> "Bert Huijben" <bert_at_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
Received on 2015-01-22 01:52:48 CET