[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Cory Riddell <cory_at_codeware.com>
Date: Thu, 22 Jan 2015 09:35:37 -0600

On 1/22/2015 8:09 AM, Evgeny Kotkov wrote:
> 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".

If I change the file name to "should-not-ever-exist", I get the exact
same output.

> 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.

Now this is strange. I started Process Monitor (PM) and now I get
different behavior. The first call to apr_file_remove now returns ENOENT
(720002).

So I went to my server, started PM and executed svnadmin hotcopy and it
finished successfully. I deleted the repository copy, shut down PM and
repeated the svnadmin hotcopy command and it failed in the same way.

In other words, the hotcopy succeeds if PM is running. Heisenberg in action?

In the PM log, there are lots of accesses to C:\Windows\CSC which is the
client side cache for network files. I wonder if Windows' offline-files
capabilities are getting in the way here? Even so, the change that you
have discussed should resolve this problem and I think it's a reasonable
change.

Cory
Received on 2015-01-22 16:37:00 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.