Iso 9660 improvements - #8
Conversation
Enforce that all ISO-9660 volume descriptors have the correct id (CD001).
Do not choke on AA (Apple) extension entries, by not enforcing any version number for generic (unknown) extension entry types. Do not choke on apparently malformed SUSP data; instead, silently abort the scan and ignore any remaing extension data. Don't bother to store the ST (termination) entry if found, just abort the scan. Simplify and unify the way all SUSP extension entry objecta are constructed.
|
Can you provide an example ISO9660 file that makes the library crash? |
|
I can't share the actual file, but I was able to throw together a file by hand that produces the same error conditions. This file was created on Linux with: DiscUtils will fail opening this file because of issues in the directory entry at offset 0xC0CC. This directory contains an AA extension entry that DiscUtils does not like, due to version number > 1. I modified the directory entry, to match conditions found in many directories in the original file, as follows:
You should be able to mount this file on Linux or Windows without issue. When testing this file, you should first find a failure due to the version number (2) in the AA entry. After that is fixed, the bogus zero-byte pad following the TF entry will cause a failure. |
|
Interesting. Opening the ISO file in Windows 10 gives shortened folder names:
|
|
Thanks for the file. I've created a test vector for it and can see the issue you're mentioning. Will test out your code in just a short while. I sure hope adding test files to the solution is "best practice"... This could grow :P. |
|
I saw that too, and I don't know why it does that. Windows does not see the long file names in the iso without my modifications, either. Linux is able to read the long file names just fine. Actually, I take that back. Linux mounts the modified file just fine, but does not see the long name of apple-test.txt (the entry I modified), which suggests that Linux sees the issue in the SUSP record and throws the whole thing out. |
|
Actually, it appears that Windows just doesn't use Rockridge extensions. |
|
Thanks for your contribution. If you encounter other edge cases for input files, it'd be awesome to have samples of them in the test suite.. Being able to (correctly) parse the file formats is key.. :) |
2 participants
I have an ISO file that was causing DiscUtils to choke in several different ways. This file appears to have been written on a Mac, but I'm not entirely sure by which software. Windows and Linux both mount and scan the file without issue, and 7-Zip scans the file and reports zero errors.
These changes allow DiscUtils to safely open iso-9660 files which have Apple extensions and which have (apparently) mal-formed SUSP data which other software takes in stride.
This file contains PD (padding) SUSP entries which follow TF (timestamp) entries, but with one zero-byte of padding. I can find nothing to indicate that this padding is legal, as all SUSP entries should be strictly contiguous per IEEE P1281, so rather than attempting to detect and skip this padding, I chose to terminate the SUSP data parse operation without throwing an exception.