On 9/15/25 13:26, Pádraig Brady wrote:
On 15/09/2025 05:04, Collin Funk wrote:
With the FUTURE DIRECTIONS having the following text:
If this utility is directed to create a new directory entry that
contains any bytes that have the encoded value of a <newline>
character, implementations are encouraged to treat this as an error.
A future version of this standard may require implementations to
treat this as an error.
Hmm.
I think there is little point in restricting characters unless it's done
completely,
because if not then you have to deal with the issue anyway.
So if the restriction is done, it should be done at a low level,
perhaps as a kernel option or something. Perhaps even a translation layer
in the kernel/libc to support older existing files with problematic characters,
while disallowing new files with those chars.
Doing this higher up in user space would only be playing
whac-a-mole with the issue I think.
I completely agree: this should be done on kernel level.
For some filesystem types, the kernel e.g. already disallows certain filenames
which
are allowed on other types. This one goes into the same direction.
And as Padraig wrote, we have to deal with such files anyway, because they
either get created by other means or because existing filesystems contain them.
IMO the wish is nice - to avoid bad file names -, yet this is maybe 50 years
too late.
Have a nice day,
Berny
