9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Dave Presotto presotto@plan9.bell-labs.com
Subject: [9fans] create(2)/open(2) race for file creation
Date: Sun,  8 Feb 1998 11:10:51 -0500	[thread overview]
Message-ID: <19980208161051.n2K1RjG4iJyYI2s73sUQJ9lJG2p5DqZ3H1P5UdMHEUg@z> (raw)

This is why I got ken to introduce exclusive access files.  I
use one as a lock for a directory/file/whatever.

------ forwarded message follows ------

>From cse.psu.edu!owner-9fans Sat Feb  7 20:03:11 EST 1998
Received: from plan9.bell-labs.com ([135.104.8.6]) by plan9; Sat Feb  7 20:03:11 EST 1998
Received: from cse.psu.edu ([130.203.3.50]) by plan9; Sat Feb  7 20:03:10 EST 1998
Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) with SMTP id TAA07964; Sat, 7 Feb 1998 19:51:49 -0500 (EST)
Received: by claven.cse.psu.edu (bulk_mailer v1.5); Sat, 7 Feb 1998 19:50:41 -0500
Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.7.3) id TAA07916 for 9fans-outgoing; Sat, 7 Feb 1998 19:50:35 -0500 (EST)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.8/8.7.3) with SMTP id TAA07912 for <9fans@cse.psu.edu>; Sat, 7 Feb 1998 19:50:30 -0500 (EST)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id SAA08743 for 9fans@cse.psu.edu; Sat, 7 Feb 1998 18:27:03 -0600
Date: Sat, 7 Feb 1998 18:27:03 -0600
From: "G. David Butler" <dbSystems.com!gdb>
Message-Id: <199802080027.SAA08743@ns.dbSystems.com>
To: cse.psu.edu!9fans
Subject: [9fans] create(2)/open(2) race for file creation
Sender: cse.psu.edu!owner-9fans
Reply-To: cse.psu.edu!9fans
Precedence: bulk

What is the best way for many processes to race for a file create
with only one winner?

In /sys/src/9/port/chan.c we have in namec():

/*
 * protect against the open/create race.  This is not a complete
 * fix.  It just reduces the window.
 */

In man open(5) the algorithm for create(2) is:
if walk(5) is good {
	return open(5, OTRUNC)
} else {
	if ret = create(5) is good {
		return ret
	} else {
		return open(5, OTRUNC)
	}
}

The first idea would be to stat(2) the file and if that fails
then create(2) (That is what ape does), but if the second process
stats before the first creates... NOT!

Using the fact that one can create a file O_WRITE with permissions
that do not allow writing, one can use a stat(2), create(2, mode 0),
chmod(2) sequence as long as the amout of time between the create and
the chmod are "long enough" for the other process... NOT!

One could create the file with CHEXCL then clear the flag later
as long as you wait "long enough" for the other process to create(2)
after the stat(2)... NOT!

It would seem that what is needed is the old *NIX O_EXCL flag.

Another alternative would be to change create(2) to simply call
create(5) and return the results.  There will need to be some
cleanup of programs that assume that a create on a existing file
is OK, but if that is the case it is easy to change:

if ((fd = create(file, mode, perm)) < 0) {
	error...
}

to:

if ((fd = create(file, mode, perm)) < 0 ||
    (fd = open(file, mode|OTRUNC) < 0)) {
	error...
}

In those programs.

Any comments?

David Butler
gdb@dbSystems.com




             reply	other threads:[~1998-02-08 16:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-02-08 16:10 Dave [this message]
  -- strict thread matches above, loose matches on Subject: below --
1998-02-26 23:30 Russ
1998-02-26 23:01 G.David
1998-02-26 22:16 G.David
1998-02-26 19:33 Eric
1998-02-26  0:24 G.David
1998-02-26  0:04 G.David
1998-02-25 23:42 G.David
1998-02-10 14:34 G.David
1998-02-10  8:59 forsyth
1998-02-09 21:21 G.David
1998-02-09 16:42 G.David
1998-02-09  8:05 Dan
1998-02-08 22:48 G.David
1998-02-08 22:18 Photon
1998-02-08 21:44 Rob
1998-02-08 21:10 G.David
1998-02-08 16:52 G.David
1998-02-08 16:16 G.David
1998-02-08 15:48 G.David
1998-02-08  5:09 G.David
1998-02-08  2:01 Rob
1998-02-08  0:27 G.David

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19980208161051.n2K1RjG4iJyYI2s73sUQJ9lJG2p5DqZ3H1P5UdMHEUg@z \
    --to=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).