From: Valdis.Kletnieks@vt.edu
To: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
Cc: Michael Witten <mfwitten@gmail.com>, "Ted Ts'o" <tytso@mit.edu>,
Mike Galbraith <efault@gmx.de>, Richard Yao <ryao@ic.sunysb.edu>,
linux-kernel@vger.kernel.org
Subject: Re: UNIX Compatibility
Date: Thu, 26 May 2011 08:07:59 -0400 [thread overview]
Message-ID: <38084.1306411679@localhost> (raw)
In-Reply-To: Your message of "Thu, 26 May 2011 13:30:39 +0200." <1306409439.28597.81.camel@thorin>
[-- Attachment #1: Type: text/plain, Size: 763 bytes --]
On Thu, 26 May 2011 13:30:39 +0200, Bernd Petrovitsch said:
> Or take the "unlink a directory gives EPERM" example: why is it
> specified with an errno that indicates that the user is not allowed to
> remove it (and not that the sys-call is the wrong one).
Because on some old Unix's, it wasn't the wrong syscall...
RATIONALE
Unlinking a directory is restricted to the superuser in many historical
implementations for reasons given in link() (see also rename()).
http://pubs.opengroup.org/onlinepubs/009695399/functions/unlink.html
I've encountered at least one system (admittedly 20+ years ago), where
unlink("./") actually did work. Took me a while to correlate the weird fsck's
at reboots to the program that tried to remove './$A' when $A was unset...
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2011-05-26 12:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-24 11:49 UNIX Compatibility Richard Yao
2011-05-24 13:06 ` Theodore Tso
2011-05-24 13:54 ` Michael Witten
2011-05-24 14:49 ` Richard Yao
2011-05-24 18:16 ` Ted Ts'o
2011-05-24 18:31 ` Michael Witten
2011-05-25 4:18 ` Mike Galbraith
2011-05-25 14:20 ` Michael Witten
2011-05-25 14:36 ` Ted Ts'o
2011-05-25 15:17 ` Michael Witten
2011-05-25 17:38 ` Ted Ts'o
2011-05-25 20:33 ` Casey Schaufler
2011-05-26 11:30 ` Bernd Petrovitsch
2011-05-26 11:30 ` Bernd Petrovitsch
2011-05-26 12:07 ` Valdis.Kletnieks [this message]
2011-05-26 12:24 ` Bernd Petrovitsch
2011-05-26 13:35 ` Ted Ts'o
2011-05-25 21:06 ` Valdis.Kletnieks
2011-05-25 14:38 ` Ted Ts'o
2011-05-25 15:17 ` Mike Galbraith
2011-05-25 15:21 ` Michael Witten
2011-05-24 18:23 ` 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=38084.1306411679@localhost \
--to=valdis.kletnieks@vt.edu \
--cc=bernd@petrovitsch.priv.at \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mfwitten@gmail.com \
--cc=ryao@ic.sunysb.edu \
--cc=tytso@mit.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.