Allow unlink/rename of files open by another process on Win32, using a
special Win32 open flag FILE_SHARE_DELETE.
Patch applied. Thanks.
---
Claudio Natoli wrote:
>
> Revised patch, for application to HEAD [open.c destine
Revised patch, for application to HEAD [open.c destined for src/port]
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em
ailpolicy.html
> Agreed, we still need dirmod.c in case someone has opened it using a
non-unix mode.
Ok. Wanted to make sure I was on the same page.
> My only question was whether this new mode makes rename
> possible on a target file opened by another backend.
Looks good. Wrote a pair of 2 liner driver pr
Claudio Natoli wrote:
>
>
> > Claudio, how does this handle renames if the file is open by someone
> > else? Does this remove the need to loop over the rename?
>
> To be honest, I don't know that it does. [Will report back later.]
>
> Two points though:
>
> a) This could doesn't alleviate th
> a) This could doesn't alleviate the needs for dirmod.c, as
This CODE doesn't alleviate the NEED for...
Sheesh,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
http://www.memetrics.com/emailpolicy.h
> Claudio, how does this handle renames if the file is open by someone
> else? Does this remove the need to loop over the rename?
To be honest, I don't know that it does. [Will report back later.]
Two points though:
a) This could doesn't alleviate the needs for dirmod.c, as far as I'm aware.
