4 ms·

> Filenames are limited to 8.3 That is not true at all, not even in the original version of iso9660. And tou might argue UTF16 is a problem, but it is _strict

> Filenames are limited to 8.3 That is not true at all, not even in the original version of iso9660. And tou might argue UTF16 is a problem, but it is _strictly_ better than most UNIXy filesystems, that _do not standarize a character set at all_ and therefore leave that big part of the problem to you. Not hard to find ext images with mojibake...

deleted 2y ago
[deleted]
inferiorhuman 2y ago
That is not true at all, not even in the original version of iso9660. ISO 9660 Level 1 specifies 8.3, Levels 2 & 3 allow up to 30 characters. There is room in the structure for longer names but that is not standard compliant which is why you have competing extensions for LFNs. it is _strictly_ better than most UNIXy filesystems NTFS, HFS+ and later are UTF-16, ZFS is UTF-8. ext4 is the odd man out here. Joliet being UTF-16 isn't better it's roughly the same. RockRidge allowing UTF-8 isn't much better because most stuff will still encode RockRidge with big endian UTF-16. UTF-16 isn't great, and perhaps defensible at the time, but big endian UTF-16 is just asinine.
- AshamedCaptain 2y ago
  > which is why you have competing extensions for LFNs. This is Microsoft in the 90s so we all know why we have competing incompatible extensions. Or rather, why there are exactly two competing extensions: the one every non-MS operating system uses, designed by the 9660 working group itself and released as an open IEEE standard; and then the proprietary MS one. Anyway, as you can see, ISO is not limited to "8.3". > NTFS, HFS+ and later are UTF-16, ZFS is UTF-8. ext4 is the odd man out here. No, the opposite. If anything, ZFS is the exception, and I'm not particularly sure you are correct there either, as it will likely break some Linux users. But I can count the list of file systems that standardize a encoding with my two hands; _every other filesystem_ does not impose one. Not even FAT does...

deleted 2y ago

[deleted]

inferiorhuman 2y ago

That is not true at all, not even in the original version of iso9660. ISO 9660 Level 1 specifies 8.3, Levels 2 & 3 allow up to 30 characters. There is room in the structure for longer names but that is not standard compliant which is why you have competing extensions for LFNs. it is _strictly_ better than most UNIXy filesystems NTFS, HFS+ and later are UTF-16, ZFS is UTF-8. ext4 is the odd man out here. Joliet being UTF-16 isn't better it's roughly the same. RockRidge allowing UTF-8 isn't much better because most stuff will still encode RockRidge with big endian UTF-16. UTF-16 isn't great, and perhaps defensible at the time, but big endian UTF-16 is just asinine.

AshamedCaptain 2y ago
> which is why you have competing extensions for LFNs. This is Microsoft in the 90s so we all know why we have competing incompatible extensions. Or rather, why there are exactly two competing extensions: the one every non-MS operating system uses, designed by the 9660 working group itself and released as an open IEEE standard; and then the proprietary MS one. Anyway, as you can see, ISO is not limited to "8.3". > NTFS, HFS+ and later are UTF-16, ZFS is UTF-8. ext4 is the odd man out here. No, the opposite. If anything, ZFS is the exception, and I'm not particularly sure you are correct there either, as it will likely break some Linux users. But I can count the list of file systems that standardize a encoding with my two hands; _every other filesystem_ does not impose one. Not even FAT does...