RE: Unable to hotcopy to a NAS shared directory: E720002
From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 21 Jan 2015 20:43:22 +0100
> -----Original Message-----
For something to return access denied on Windows it must exist.
> svn_io_set_file_read_write() passing ignore_enoent. That function has
> svn_io_set_file_read_write() also doesn't have a WIN32_RETRY_LOOP. Are
File attributes are typically not involved with locking of the files.
I prefer *not* to loop when in doubt, as bad loops can cause much bigger problems than a forgotten loop.
A loop that just waits for something that isn't going to fix itself, is just a 12 second delay... Turn yet another delay loop around that in its caller and you are waiting for minutes. Another loop around that and it will be days.
We had quite a few bugs in previous versions, where scenarios could cause major lockups caused by retries waiting for the wrong error conditions.
The problem here is that we have a NAS that shows itself as a Windows device, but behaves differently.
A typical Windows test run *never* triggers a retry loop for IO errors... nor should it.
The io retry loops are workarounds for externally caused problems. Virusscanners, etc.
In this case: are we really saying that hotcopy should work to a network drive?
Even if it doesn't support the proper locking primitives?
Perhaps the proper recommendation is: hotcopy to a local drive first, and then copy to network storage.
This is an archived mail posted to the Subversion Dev mailing list.