Re: [PATCH v3 0/5] make open/unlink failures user friendly on windows using retry/abort

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 14, 2010 at 11:06 PM, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote:
> 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)?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]