Re: [PATCH v3 0/5] make open/unlink failures user friendly on windows using retry/abort
- From
Erik Faye-Lund <kusmabite@gmail.com>
- Date
- Dec 15, 2010, 15:52 UTC
- Message-ID
- <AANLkTiks1drfpu9eR6S7KQ9X2MgVy91QAfKs-SRF_voG@mail.gmail.com>
- In-Reply-To
- <20101214220604.GA4084@sandbox>
On Tue, Dec 14, 2010 at 11:06 PM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
Show 36 quoted lines
> Hi, > > On Wed, Nov 10, 2010 at 09:32:00PM +0100, Johannes Sixt wrote: >> On Dienstag, 9. November 2010, Heiko Voigt wrote: >> > So it seems that unlink also has the problem of getting an >> > ERROR_ACCESS_DENIED (Code 5) sometimes. Johannes would you agree that >> > including this code into the is_file_in_use_error() function and thus >> > having the potential risk of a 71ms delay for real access denials for >> > these calls makes sense? >> >> Of course, it matches my own observations. > > Sorry for the delay. Here is finally a new iteration of the patch > series. I hope I have addressed all raised issues. An extra pair of eyes > is appreciated. > > This series has been ported to Junios tree. > > I also added one patch from Johannes which I think should be part of > this series. > > Cheers Heiko > > Heiko Voigt (4): > mingw: move unlink wrapper to mingw.c > mingw: work around irregular failures of unlink on windows > mingw: make failures to unlink or move raise a question > mingw: add fallback for rmdir in case directory is in use > > Johannes Schindelin (1): > mingw_rmdir: set errno=ENOTEMPTY when appropriate > > compat/mingw.c | 172 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- > compat/mingw.h | 14 ++--- > 2 files changed, 177 insertions(+), 9 deletions(-) >
I like the goal of the series (and enjoy the end-result on mingw), but the more I think of this the more I wonder if this is solving the problem on the wrong abstraction level.
POSIX says that unlink et al can set errno to EBUSY if a file is in use and the implementation considers that an error. I suspect they had a reason for adding that, and I doubt that reason was Windows. POSIX is already pretty incompatible with Windows. Some Googling have suggested (but I haven't found definitive proof) that some flavors of QNX (depending on the file system used, it seems) and Solaris might be affected. Even Linux seems to be affected if the NTFS 3G driver is used. Perhaps we've only seen this on Windows so far because anti-virus is uncommon on these other systems? Perhaps something like Dropbox-syncing on a mounted NTFS drive under Linux can cause this in real life as well?
Perhaps instead we would be better of with something like an xunlink (etc) in wrapper.c that deals with this on all platforms (and make sure that unlink sets errno to EBUSY correctly if it doesn't already)?