DiskFSDOS33::ProcessCatalogSector() correctly avoids attempting to process unused catalog entries (track=$00), but doesn't stop scanning when one is encountered. This can lead to problems.
I'm not entirely sure how this situation arises. Normally, catalog entries are allocated in order, and deleted entries are marked with track=$ff. A catalog track should be a mix of valid and deleted entries, followed by a collection of zeroed-out data.
https://web.archive.org/web/20160404041534/http://www.6502lane.net/2015/03/16/source-code-and-distribution-images-for-don-worths-beneath-apple-manor/ has an example of where things went weird. The page has a screen shot of CiderPress complaining about a disk with the Beneath Apple Manor source on it. It appears that the file CORRIDOR is damaged. However, if you look at the catalog listing, you'll see that there's a valid file called CORRIDOR just below the error dialog. The disk structure is actually just fine.
The problem is on track 17 sector 10:
00: 00 11 09 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0b 06 ................
30: 04 c3 cf d2 d2 c9 c4 cf d2 a0 a0 a0 a0 a0 a0 a0 .CORRIDOR
40: a0 a0 a0 a0 a0 a0 a0 a0 a0 a0 a0 a0 a0 a0 a0 03 .
50: 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
The byte at +$0b indicates that the first entry is unused, but the second entry at +$2e has a valid T/S link. The sector linked is not a T/S list entry, though, so the file appears to be damaged. This in turn causes the disk to be regarded as unsafe.
The fix is to break out of the catalog sector scan loop when an unused entry is found, and return a value to the caller to tell it not to process any additional sectors.
DiskFSDOS33::ProcessCatalogSector()correctly avoids attempting to process unused catalog entries (track=$00), but doesn't stop scanning when one is encountered. This can lead to problems.I'm not entirely sure how this situation arises. Normally, catalog entries are allocated in order, and deleted entries are marked with track=$ff. A catalog track should be a mix of valid and deleted entries, followed by a collection of zeroed-out data.
https://web.archive.org/web/20160404041534/http://www.6502lane.net/2015/03/16/source-code-and-distribution-images-for-don-worths-beneath-apple-manor/ has an example of where things went weird. The page has a screen shot of CiderPress complaining about a disk with the Beneath Apple Manor source on it. It appears that the file CORRIDOR is damaged. However, if you look at the catalog listing, you'll see that there's a valid file called CORRIDOR just below the error dialog. The disk structure is actually just fine.
The problem is on track 17 sector 10:
The byte at +$0b indicates that the first entry is unused, but the second entry at +$2e has a valid T/S link. The sector linked is not a T/S list entry, though, so the file appears to be damaged. This in turn causes the disk to be regarded as unsafe.
The fix is to break out of the catalog sector scan loop when an unused entry is found, and return a value to the caller to tell it not to process any additional sectors.