[RFC] unlink() implementation

Corinna Vinschen vinschen@redhat.com
Sat Oct 11 08:32:00 GMT 2003


On Fri, Oct 10, 2003 at 07:16:06PM -0400, Pierre A. Humblet wrote:
> At 10:18 PM 10/10/2003 +0200, Corinna Vinschen wrote:
> >Third, even FILE_FLAG_DELETE_ON_CLOSE has no effect on 9x, even though
> >MSDN does not mention any problem with that flag on 9x/Me.
> 
> If that was the case then the 1.5.5 rm wouldn't work on 9x even with
> files that are not opened, and there would be a lot more complaints!

Erm, I thought it was clear I'm talking about files which are still
opened by the same or another process.  I could change that CreateFile
call to succeed always, also with files opened for writing...

> If the file is already opened, CreateFile (FILE_FLAG_DELETE_ON_CLOSE)
> incorrectly appears to succeed if the file was opened for reading, 
> but fails if it was opened for writing.
> Without the FILE_SHARE_READ, it always fails if the file is already opened,
> which is what we want (FILE_SHARE_READ might be needed for some other
> reason, although I think it's a relic of the past).

...by adding FILE_SHARE_WRITE to that CreateFile call but in no case
it removed the file after all handles had been closed, so...

> In other words, on 9x FILE_FLAG_DELETE_ON_CLOSE (without FILE_SHARE_XX)
> seems to work exactly as DeleteFile.
> Given the mixed experience with FILE_FLAG_DELETE_ON_CLOSE, I'd rather use
> DeleteFile.

...that extra functionality is pretty worthless.  DeleteFile does the
same.  I thought that was clear.  Sorry for assuming too much.

> >Step 1 (Only on NT):
> >
> >    Try CreateFile(FILE_FLAG_DELETE_ON_CLOSE)/CloseHandle();
> >
> >Step 2:
> >
> >    Try DeleteFile();
> 
> Are there cases where 1 fails on NT when 2 works? If not, skip 2.
> Does DeleteFile() work at all with opened file on NT?
> There must be a reason why our ancestors went to the trouble of 
> implementing 1.

The ancestor is cgf, IIRC.  The unlink function has a moved history.
However, DeleteFile on NT has a POSIX-like semantics as long as files
are opened with FILE_SHARE_DELETE access, which is true for all files
opened by Cygwin processes.  POSIX-like semantics means, DeleteFile
deletes when the last handle to the file is closed, an `ls file' fails
with "No such files...".  That's not different from the DELETE_ON_CLOSE
method.  Since DeleteFile is needed for 9x anyway, why bother with
DELETE_ON_CLOSE?  However, if you can find any situation where DeleteFile
doesn't work but DELETE_ON_CLOSE works, that's fine.  I, for one,
couldn't find such a situation when testing.  But of course I can easily
have missed one.

> >Step 3:
> >
> >    Try SHFileOperation(FO_DELETE)  // moves to Recycle Bin
> 
> I cannot place opened files in the wastebasket, so I doubt that this
> would work when we need it.

That's what I was going to test.  At least I know how to call the 
function now correctly.

> I would be surprised if early Cygwin developers hadn't tried this.

Hmm, SHFileOperation is a GUI interface function.  It's not really
obvious, is it?

> Still, if you can make it work, it's worth a try. 

I have a working test application now, I've just not tested it on 9x
so far.  Knock on wood.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.



More information about the Cygwin-developers mailing list