Thread (6 messages) 6 messages, 3 authors, 2025-04-25

Re: newlines in filenames; POSIX.1-2024

From: Christoph Hellwig <hch@infradead.org>
Date: 2025-04-25 14:54:42
Also in: linux-man, lkml

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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help