[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: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Thu, 22 Jan 2015 16:48:26 +0300

Philip Martin <philip.martin_at_wandisco.com> writes:

> Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com> writes:
>> The reason why this error is propagated up the stack is that we only examine
>> the 'ignore_enoent' argument after the first apr_file_remove() call. This is
>> racy — if we get a EACCES during the first attempt to remove a file, and the
>> file is simultaneously removed from the disk, the next attempt to remove it
>> would fail with a ENOENT, even with 'ignore_enoent'. I think we should
>> fix this by suppressing ENOENTs from every apr_file_remove() call, not
>> just the first one.
> Sounds plausible.

Here is the patch for this part of the issue. Log message:
Prevent svn_io_remove_file2() from misbehaving in certain racy situations
with ignore_enoent = TRUE.

On Windows, this function might call apr_file_remove() more than once due
to a special handling of access denied errors. However, we only handle
ENOENTs during the first call. If we happen to receive a EACCES during
the first attempt to remove a file, and the file is gone at the moment we
try again, a caller will receive an ENOENT; this will happen regardless of
the ignore_enoent argument value. Given that the caller explicitly told
us that he/she is okay with the files not being present, returning an error
is just wrong.

* subversion/libsvn_subr/io.c
  (svn_io_remove_file2): Respect ignore_enoent argument after every possible
   attempt to remove a file, including retries under WIN32. While here,
   make the conditional statements a bit more readable by splitting them.

Found by: Cory Riddell <cory{_AT_}codeware.com>
(Message-ID: <54C02169.8090506_at_codeware.com> in the users mailing list,

Any objections?

Evgeny Kotkov

Received on 2015-01-22 14:50:02 CET

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

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