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

[Christopher Faylor <cgf at redhat dot com>]

On Sun, May 06, 2001 at 03:39:49PM -0300, Neil Erskine wrote:
>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?

To delete the file when it is closed, if possible.

>Question 2: What is the race condition?

File could not be deleted because it was open/other process deletes
file/another process creats a new file/this process deletes the newly
created file, thinking it is the original file that wants to be deleted.
The end result is that a file is removed from the OS which shouldn't be.

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

Because that's the way NTFS works?

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

The net is your friend.  Look it up.

cgf

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