From: Christoph Hellwig <hch@infradead.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Alejandro Colomar <alx@kernel.org>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
linux-man@vger.kernel.org
Subject: Re: newlines in filenames; POSIX.1-2024
Date: Fri, 25 Apr 2025 07:54:42 -0700 [thread overview]
Message-ID: <aAuiMqkjVbW3c8nx@infradead.org> (raw)
In-Reply-To: <20250422222131.GE569616@mit.edu>
On Tue, Apr 22, 2025 at 05:21:31PM -0500, Theodore Ts'o wrote:
> Do we have any information of which implementations (if any) might
> decide to disallow new-line characters?
AFAIK: none. At least none that matters.
> Personally, I'm not convinced a newline is any different from any
> number of weird-sh*t characters, such as zero-width space Unicode
> characters, ASCII ETX or EOF characters, etc.
It isn't any different in a substantial way.
> I suppose we could add a new mount option which disallows the
> weird-sh*t characters, but I bet it will break some userspace
> programs, and it also begs the question of *which* weird-sh*t
> characters should be disallowed by the kernel.
Don't go there. The only limitations that does make some limited
sense in some limited environment is limiting to valid utf8. We've
already done that for CI, and that's causing enough problems despite
having a use case. Adding random mount options to limit random
characters has a lot of downside but absolutely no actual upside.
>
> > I guess there's no intention to change that behavior. But I should
> > ask. I thought of adding this paragraph to all pages that create
> > file names:
> >
> > +.SH CAVEATS
> > +POSIX.1-2024 encourages implementations to
> > +disallow creation of filenames containing new-line characters.
> > +Linux doesn't follow this,
> > +and allows using new-line characters.
> >
> > Are there any comments?
>
> I think this is giving the Austin Group way more attention/respect
> than they deserve, especially when it's an optional "encourage", but
> whatever...
Yeah. Don't even mention these idiotic recommendations, any attention
spent on this is too much.
prev parent reply other threads:[~2025-04-25 14:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-16 16:50 newlines in filenames; POSIX.1-2024 Alejandro Colomar
2025-04-22 22:21 ` Theodore Ts'o
2025-04-23 7:31 ` Alejandro Colomar
2025-04-24 0:05 ` Theodore Ts'o
2025-04-24 7:00 ` Alejandro Colomar
2025-04-25 14:54 ` Christoph Hellwig [this message]
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=aAuiMqkjVbW3c8nx@infradead.org \
--to=hch@infradead.org \
--cc=alx@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--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 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).