Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-developers-owner AT cygwin DOT com
Message-ID: <3E6CB0FA.2312CCD0@ieee.org>
Date: Mon, 10 Mar 2003 10:36:26 -0500
From: "Pierre A. Humblet" <Pierre DOT Humblet AT ieee DOT org>
MIME-Version: 1.0
To: "cygwin-developers AT cygwin DOT com" <cygwin-developers AT cygwin DOT com>
Subject: unlink
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris,

It's a great idea to use FILE_FLAG_DELETE_ON_CLOSE for unlink,
but a few bells rang when I read the code.

1) ntsec
/> mkdir testdir
/> chown 1002:1005 testdir
/> chmod +rwxt testdir
/> touch testdir/testfile
/> chmod 577 testdir/testfile
/> rm -f testdir/testfile
rm: cannot unlink `testdir/testfile': Permission denied

The problem is the DELETE flag in alloc_sd (and sec_acl). Corinna
has put effort into that and when I first saw that code I thought 
it was an excellent idea. With the benefit of hindsight I now think it's 
counterproductive. POSIX semantics do not support a delete permission 
in the Windows sense. Not allowing DELETE in one spot forces us
to *automatically* add it in unlink, so it doesn't help at all from
a Cygwin user point of view.

On the other hand, if a Windows user goes out of Cygwin to remove
DELETE permission on a file, then one could argue that unlink should
fail. Some other action should be required from the user, unlink
shouldn't go out of its way to delete the file.
This is symmetric to refusing to delete a file in a non-writable 
directory even though Windows allows it (err on the side of caution).

So I would propose to remove the DELETE code from alloc_sd and sec_acl
and to leave unlink as it is, in that respect.

2) Why is wincap.has_delete_on_close needed?

All Windows versions have delete_on_close capability. This is a snippet
on WinME with a file on a shared directory mounted on Win98.

  152  325366 [main] rm 36050599 unlink: _unlink (e:\xx)
 6422  331788 [main] rm 36050599 unlink: 1 = CloseHandle (0xCC)
 1237  333025 [main] rm 36050599 unlink: CreateFile (FILE_FLAG_DELETE_ON_CLOSE) succeeded
  158  333183 [main] rm 36050599 unlink: 0 = unlink (/e/xx)

However Win95 does not have FILE_SHARE_DELETE, so if the file is already opened
the CreateFile fails (and wincap.has_delete_on_close won't be looked up).

Is there reason to believe that a file won't be deleted if the CreateFile succeeds?
It would violate MS semantics. I couldn't create such a case, but I don't have 
access to many types of shared drive. Perhaps the test after the CloseHandle could be
  if (win32_name.isremote () && GetFileAttributes (win32_name) != INVALID_FILE_ATTRIBUTES)
    then handle CreateFile (FILE_FLAG_DELETE_ON_CLOSE) failed

3) I don't understand why there are so many SetFileAttributes after CreateFile
   succeeds. If the file will be deleted, its attributes are don't care. If it won't,
   then we undo twice what we just did before the CreateFile.
   Also it's an easy test to decide if the SetFileAttribute before CreateFile is needed.

Pierre