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,
http://svn.haxx.se/users/archive-2015-01/0082.shtml)
]]]
Any objections?
Regards,
Evgeny Kotkov
Received on 2015-01-22 14:50:02 CET