4 ms·

In general, the ISO9660 format is great for distributing disk images for this reason: it's a mature, international, cross-platform standard. ISO 9660 is a st

In general, the ISO9660 format is great for distributing disk images for this reason: it's a mature, international, cross-platform standard. ISO 9660 is a standard, yes. But what's actually standardized by ISO 9660 is exceptionally limited. Filenames are limited to 8.3 with a quite small character set literally just A-Z, 0-9, _, and a single dot. There are competing long file name standards, Microsoft's uses big endian UTF-16 as is tradition. The RockRidge extensions define support for POSIX semantics, unsure how well supported the POSIX permissions are. MacOS can indeed mount supported ISO 9660 images from the Finder. One of the big advantage of ISO 9660 (and I assume UDF) is that the superblock does not conflict with the HFS superblock so you do both with relative ease. The other big one is that ISO 9660 is quite simple to implement compared to the alternatives.

alexey-salmin 2y ago
> The RockRidge extensions define support for POSIX semantics, unsure how well supported the POSIX permissions are. Permissions are supported. I'd even say they are supported more than it is reasonable. It resulted in some rather painful mistakes when preparing a media if you're not experienced enough. I'm speaking not of an OS distribution, but rather of a quick CD you burned to share some files with your friend in 2004. You could make files only readable under root, unless CD is re-mounted with specific options which probably aren't available to a non-root user in the first place. You could set suid/sgid bits. You could set a userid which is useless on a target machine (can be remapped when mounting of course). Whereas all you really wanted in the first place was just "r" (not even "rrr") for data files and "rx" (again, not "rxrxrx") for binaries and directories. Curiously reading "man mkisofs" now I see there's an option "-r" which is like "-R but reasonable". This would've helped me a great deal back then, I wonder if it existed and I just wasn't aware.
- josephcsible 2y ago
  > You could make files only readable under root, unless CD is re-mounted with specific options which probably aren't available to a non-root user in the first place. Doesn't Linux give non-root users read access to the CD's block device? And with that, couldn't you read whatever files you wanted anyway?
AshamedCaptain 2y ago
> 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...

alexey-salmin 2y ago

> The RockRidge extensions define support for POSIX semantics, unsure how well supported the POSIX permissions are. Permissions are supported. I'd even say they are supported more than it is reasonable. It resulted in some rather painful mistakes when preparing a media if you're not experienced enough. I'm speaking not of an OS distribution, but rather of a quick CD you burned to share some files with your friend in 2004. You could make files only readable under root, unless CD is re-mounted with specific options which probably aren't available to a non-root user in the first place. You could set suid/sgid bits. You could set a userid which is useless on a target machine (can be remapped when mounting of course). Whereas all you really wanted in the first place was just "r" (not even "rrr") for data files and "rx" (again, not "rxrxrx") for binaries and directories. Curiously reading "man mkisofs" now I see there's an option "-r" which is like "-R but reasonable". This would've helped me a great deal back then, I wonder if it existed and I just wasn't aware.

josephcsible 2y ago
> You could make files only readable under root, unless CD is re-mounted with specific options which probably aren't available to a non-root user in the first place. Doesn't Linux give non-root users read access to the CD's block device? And with that, couldn't you read whatever files you wanted anyway?

AshamedCaptain 2y ago

> 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...