Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Date:	Sun, 6 May 2001 14:59:08 -0400
From:	Christopher Faylor <cgf AT redhat DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Rationale for unlink algorithm in syscalls.cc. What is the race condition?
Message-ID:	<20010506145908.C6923@redhat.com>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<CAEIIBEHOJELFDAHENHIAEIICDAA DOT neil DOT erskine AT jjmackay DOT ca>
Mime-Version:	1.0
User-Agent:	Mutt/1.3.11i
In-Reply-To:	<CAEIIBEHOJELFDAHENHIAEIICDAA.neil.erskine@jjmackay.ca>; from neil.erskine@jjmackay.ca on Sun, May 06, 2001 at 03:39:49PM -0300

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

- Raw text -