All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Jonny Grant <jg@jguk.org>
Cc: linux-ext4@vger.kernel.org
Subject: Re: /fs/ext4/namei.c ext4_find_dest_de()
Date: Wed, 27 May 2020 21:12:21 -0400	[thread overview]
Message-ID: <20200528011221.GC228632@mit.edu> (raw)
In-Reply-To: <e6e172ae-ba19-f303-3aa9-a388adba8cb0@jguk.org>

On Wed, May 27, 2020 at 10:25:43PM +0100, Jonny Grant wrote:
> 
> 
> How about adding an improved mkdir to POSIX and the Linux kernel? Let's call it mkdir2()
> 
> It has one more error, for EISDIR
> 
> [EEXIST]
> The named file exists.
> 
> [EISDIR]
> Directory with that name exists.

It's *really* not worth it.

You seem to really care about this; why don't you just keep your own
version of shellutils which calls stat(1) if you get EEXIST and to
distinguish between these two cases?

I know the shellutils maintainers has rejected this.  But that's OK,
you can have your own copy on your systems.  You might want to reflect
that if the shellutils maintainer refused to add the stat(1) on the
error path, what makes you think they will accept a change to use a
non-standard mkdir2() system call?

If you want to try to convince Austin Common Standards Revision Group
that it's worth it to mandate a whole new system call *just* for a new
error code, you're welcome to try.  I suspect you will not get a good
reception, and even if you did, Linux VFS maintainer may well very
well deride the proposal as silly, and refuse to follow the lead of
the Austin group.  In fact, Al Viro is very likely not to be as
politic as I have been.  (It's likely the response would have included
things like "idiotic idea" and "stupid".)

> I'm tempted to suggest this new function mkdir2() returns 0 on success, or
> an error number directly number. That would do away with 'errno' for this as
> well.

This is not going to get a good reception from either Al or the Austin
Group, I predict.  If you really have strong ideas of what you think
an OS and its interfaces should look like, perhaps you should just
design your own OS from scratch.

Best regards,

						- Ted

  reply	other threads:[~2020-05-28  1:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-03 13:00 /fs/ext4/namei.c ext4_find_dest_de() Jonny Grant
2020-05-04  1:51 ` Theodore Y. Ts'o
2020-05-04  7:38   ` Jonny Grant
2020-05-04 19:52     ` Theodore Y. Ts'o
2020-05-05 18:07       ` Jonny Grant
2020-05-05 18:50         ` Andreas Dilger
2020-05-07 11:25           ` Jonny Grant
2020-05-27 21:25   ` Jonny Grant
2020-05-28  1:12     ` Theodore Y. Ts'o [this message]
2020-06-08  1:39       ` Jonny Grant

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=20200528011221.GC228632@mit.edu \
    --to=tytso@mit.edu \
    --cc=jg@jguk.org \
    --cc=linux-ext4@vger.kernel.org \
    /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.