And I maintain that's a bug. Kernels should be doing:
* UTF-8 normalization
* Leading and trailing space elimination
* Banning leading dashes
* Banning non-printable unicode characters
There's absolutely no reason for treating filenames as opaque strings, except that by doing so, you avoid having arguments about encodings. Now that UTF-8 has won, we should revisit that decision.
Posted Nov 17, 2012 1:39 UTC (Sat) by anselm (subscriber, #2796)
[Link]
UTF-8 normalisation probably makes sense, but disallowing leading dashes in filenames would disable potentially desirable features like being able to create a file called »-i« in a directory where you don't want to accidentally have »rm *« delete all your files.
Potential pitfalls in DNS handling
Posted Nov 17, 2012 2:13 UTC (Sat) by apoelstra (subscriber, #75205)
[Link]
> UTF-8 normalisation probably makes sense, but disallowing leading dashes in filenames would disable potentially desirable features like being able to create a file called »-i« in a directory where you don't want to accidentally have »rm *« delete all your files.
Nor would it allow creating "-r" in directories where you want rm to be extra destructive. :)
Potential pitfalls in DNS handling
Posted Nov 17, 2012 15:13 UTC (Sat) by Jandar (subscriber, #85683)
[Link]
It is not the kernels job to judge the userspace character-encodings or other aspects of filenames. If we follow this path would more than one dot legal, why ban only leading and trailing spaces? And think of the children, disallow NSFW words in filenames or file-content ;-).
Potential pitfalls in DNS handling
Posted Nov 19, 2012 10:51 UTC (Mon) by cesarb (subscriber, #6266)
[Link]