> > I find it very unlikely that you would "during normal operations"
end up
> > in a situation where you would first have permissions to create
files in
> > a directory, and then lose them.
> > What could be is that you have a directory where you never had
> > permissions to create the file in the first place.
> > Any chance to differentiate between these?
> The cases we're concerned about involve access to an existing file,
> attempts to create a new one, so I'm not clear what your point is.

I am wondering if we can delete the file by opening it with
FILE_FLAG_DELETE_ON_CLOSE, and immediately close it again. 
The semantics should be clear if we let the OS delete the file after the

last handle on it is closed ? 
Until all handles are closed another process can still open it with 
FILE_SHARE_DELETE (according to docs), but not without the flag.
This seems to be what we want.

If this fails (see the loop in dirmod.c) we could try to move it to
the recycle bin with SHFileOperation with FO_DELETE.

It seems the win unlink is not implemented correctly and we need to
replace it.
I don't feel easy with the ignore EACCES idea. 

Should I try to supply a patch along this line ?


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to