Bernhard Voelker <m...@bernhard-voelker.de> writes: > 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.
Thanks both for the input. Your thoughts aren't too far from mine. That is, ignore this part of POSIX as long as it is only a suggestion. If there is a discussion on the POSIX bug tracker to make it a requirement, we can revisit it then, and likely voice objections there. Collin
