Evgeny Kotkov <evgeny.kot...@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. Windows code is tricky. When svn_io_remove_file2() gets EACCES it calls svn_io_set_file_read_write() passing ignore_enoent. That function has different handling of ignore_enoent as it only checks ENOENT while svn_io_remove_file2() and checks both ENOENT and ENOTDIR. svn_io_set_file_read_write() also doesn't have a WIN32_RETRY_LOOP. Are those differences intentional? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
