Filesystems and case-insensitivity

Posted Nov 28, 2018 20:20 UTC (Wed) by saffroy (guest, #43999)
In reply to: Filesystems and case-insensitivity by perennialmind
Parent article: Filesystems and case-insensitivity

I agree that allowing invalid byte sequences seems dangerous.

However, I wouldn't go as far as forbidding valid characters, that would be a different feature; blocking sequences that invalid for the selected encoding is sufficient.

Filesystems and case-insensitivity

Posted Nov 28, 2018 21:07 UTC (Wed) by perennialmind (guest, #45817) [Link] (1 responses)

If I understand you correctly, I agree. Adding filename-as-natural-language-text semantics rounds off one of the many sharp edges in shell scripting. Adding bumpers around the rest is a separate task.

If the semantics really are to be changed – if a differentiable set of path elements are to contain text and only text – that's a useful feature from an application developer's perspective. If it's to be a new kind of hard-to-predict weirdness, that's less useful.

I'd prefer it if text-only filenames were limited to printable graphemes only. That might be too high a bar. I would hope that control characters (C0,C1) would be disallowed. I don't consider \x7F (DELETE) or \x09 (TAB) to be valid in a natural-language name.

Filesystems and case-insensitivity

Posted Dec 6, 2018 10:02 UTC (Thu) by Wol (subscriber, #4433) [Link]

I worked with a system that had filenames of the form <space><backspace>NNNN

Bearing in mind users weren't supposed to go anywhere near them, it was a pretty good way of stopping people scanning the filesystem and messing about with them. I agree for user visible files, it's a good idea, but not all files are meant to be user visible and some of them can't be hidden.

Cheers,
Wol

Filesystems and case-insensitivity

Posted Nov 28, 2018 22:10 UTC (Wed) by quotemstr (subscriber, #45331) [Link] (7 responses)

I've yet to hear any good justification for allowing a formfeed in a filename.

Filesystems and case-insensitivity

Posted Nov 29, 2018 6:39 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (1 responses)

Is "there could already be files with a form feed in their name" a good justification?

Filesystems and case-insensitivity

Posted Nov 29, 2018 21:04 UTC (Thu) by perennialmind (guest, #45817) [Link]

That would be a potential problem for a mount option, but not when setting a per-directory attribute, since the directory must be empty. The same problem applies to the name collision problem though. Imposing new semantics on a filesystem would be problematic. Maybe with a superblock change? Meh. The per-directory attribute just seems cleaner overall.

Filesystems and case-insensitivity

Posted Nov 29, 2018 9:11 UTC (Thu) by dgm (subscriber, #49227) [Link] (4 responses)

> I've yet to hear any good justification for allowing a formfeed in a filename.

You cannot have formfeeds in a file name. You can have bytes with the decimal value 12, but reading it as a formfeed or somethig else is completely up to you.

Filesystems and case-insensitivity

Posted Nov 29, 2018 10:46 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

What's the difference in practice then?

Seriously, the idiocy with free-form filenames should be fixed.

Filesystems and case-insensitivity

Posted Nov 29, 2018 12:43 UTC (Thu) by hkario (subscriber, #94864) [Link] (2 responses)

because that file could have been created on a system working in CP437 where it would be shown as ♀

Just because a byte string is an invalid sequence in one encoding doesn't mean it's an invalid sequence in all encodings.

Filesystems and case-insensitivity

Posted Nov 29, 2018 18:28 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

UTF-8 won. We should start giving it its well-earned victory parade. Don't you that, after we're finished banning non-UTF-8 encodings, and after we ban illegal or bizarre code sequences, and after we start normalizing filenames into consistent form, we'll end up in a better place? If in the process of doing that we can't access files called ♀ from old volumes without special compatibility mount options, so be it.

Filesystems and case-insensitivity

Posted Nov 29, 2018 20:47 UTC (Thu) by perennialmind (guest, #45817) [Link]

That's why I thought it was a brilliant choice to require that directories be empty in order to switch on the "text mode dentries" attribute. You sidestep the "reinterpret" problem in trade for a save/copy errors that are easy to surface to end users. I'm not sure how overlayfs union mounts would work though.