This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Rationale for unlink algorithm in syscalls.cc. What is the race condition?


I am testing unlink for read-only files, which exhibits some problems.  The
algorithm used is peculiar (at least to my mind), and the only comments
present are cyptic references to known, but not described, bugs.

When attempting to unlink a file, syscalls.cc invokes the following
algorithm:

DeleteFile(name)

if DeleteFile didn't work,
   /* FIXME. There is a race here. */
   CreateFile(name, READONLY, EXISTINGONLY, DELETEONCLOSE)
   if CreateFile worked
      CloseFile
      if Os is NT or can't get file attributes
         if worked, return success
      end if
   end if

   chmod (name, full access rights)
   DeleteFile(name)
   if DeleteFile didn't work
       fail
   end if
end if

The comment about the race condition is in the code.
DeleteFile always fails for read-only files, but the CreateFile operation
succeeds or fails depending on the filesystem type.

Question 1: Why is the Create/Open sequence here at all?

Question 2: What is the race condition?

Question 3: Why does the Create fail on NTFS file systems for read only
files?

Question 4: What is the DELETE_ON_CLOSE flag for? The file is not deleted on
            Novell filesystems (where the Create succeeds).

Neil Erskine

voice 902 423 7727 ext. 230
fax 902 422 8108


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]