From: "rob pike" <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] union directories
Date: Wed, 21 Mar 2001 22:28:37 -0500 [thread overview]
Message-ID: <20010322032845.A4AE7199E7@mail.cse.psu.edu> (raw)
The manual says "creation goes to the first element of the union that
permits creation". Doesn't that means that it shoud jump non_writable?.
Actually, the manual page bind(1) says,
[-c] can be used in addition to any of the above to permit
creation in a union directory.
When a new file is created in a union directory,
it is placed in the first element of the union that permits creation.
In this context, I don't feel it's ambiguous.
Bind(2) says,
When a create system call (see open (2)) attempts to create in a union
directory, and the file does not exist, the elements of the union are
searched in order until one is found with MCREATE set. The file is
created in that directory; if that attempt fails, the create fails.
which is even clearer.
As to what it *should* do, this topic was one of the most discussed
in the early days of the system. The current behavior obviously
reflects an easy implementation. It's worked well in practice but
better designs may exist.
Lookup should win whenever creation wins.
I'm not sure what this means. There's no "winning" going on, and
lookup cannot work the same as creation if the file does not exist,
since there's nothing to look up. If there is an existing file with that
name, in any element of the union, it is the one to which creation
will always apply.
This is all a legacy of Unix's model that create means two different
things in the two situations.
-rob
next reply other threads:[~2001-03-22 3:28 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-22 3:28 rob pike [this message]
2001-03-23 10:06 ` Douglas A. Gwyn
-- strict thread matches above, loose matches on Subject: below --
2003-03-03 20:45 Keith Nash
2003-03-03 20:51 ` Russ Cox
2003-03-03 20:00 Keith Nash
2003-03-03 20:05 ` Russ Cox
2003-03-03 18:58 rog
2003-03-03 23:17 ` anyrhine
2003-03-03 13:18 rog
2003-03-03 17:40 ` Ronald G. Minnich
2003-03-03 18:05 ` Russ Cox
2003-03-03 18:09 ` Ronald G. Minnich
2003-03-03 18:16 ` Russ Cox
2003-02-28 18:52 Joel Salomon
2003-02-28 18:56 ` Russ Cox
2003-02-28 21:16 ` Jack Johnson
2003-02-28 22:58 ` Geoff Collyer
2003-02-28 23:19 ` Jack Johnson
2003-02-28 23:59 ` Geoff Collyer
2003-02-15 19:37 [9fans] presentation preparation Scott Schwartz
2003-02-15 19:48 ` andrey mirtchovski
2003-02-27 9:35 ` Ralph Corderoy
2003-02-28 18:44 ` [9fans] union directories Jack Johnson
2003-02-28 18:53 ` Russ Cox
2003-03-04 9:44 ` Adrian Tritschler
2001-03-23 13:30 G. David Butler
2001-03-23 13:08 rog
2001-03-26 8:44 ` Douglas A. Gwyn
2001-03-22 2:57 Gorka Guardiola Muzquiz
2001-03-22 2:46 Gorka Guardiola Muzquiz
2001-03-22 2:42 Gorka Guardiola Muzquiz
2001-03-22 2:37 Russ Cox
2001-03-22 2:02 Russ Cox
2001-03-22 1:56 Gorka Guardiola Muzquiz
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=20010322032845.A4AE7199E7@mail.cse.psu.edu \
--to=rob@plan9.bell-labs.com \
--cc=9fans@cse.psu.edu \
/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).