Sparse files can be incompatible with GS/OS about ciderpress

[fadden]

I've been able to reproduce an issue. It appears that a file with nothing but zeroes can be represented as fully sparse, but a file that starts with zeroes and then has some nonzero values must have an explicitly-allocated block 0, or you can get failures. So far I've only seen them happen when the file is > 128KB (the transition from "sapling" to "tree" structure). I suspect the problem is that there must be at least one block allocated in the first 128KB, so that the first block in the tree's master block list is allocated.

[fadden]

I've seen Copy ][+ fail on such files (see issue #15), but I was not aware that the ProDOS FST had issues. What version of GS/OS are you using? Can you attach a disk image with a file that fails?

[fadden]

A ran some tests. A file with 1024 zeroes stored in a ShrinkIt archive occupies 3 blocks when extracted by P8 ShrinkIt, but only 1 block when extracted by GS/ShrinkIt, and 1 block when created by CiderPress. Looking at the directory entry, GS/OS set the storage type to 5 (forked) for all files, while P8 set it to 2. P8 ShrinkIt is able to "type" files extracted by either (it just can't open resource forks).

So both GS/OS and P8 are able to handle files with an initial sparse block. I'm not sure why you're seeing failures / corruption.

[ibrumby]

Glad you have been able to reproduce it. I noticed it on a tree, but another person on the Slack has seen it on a 34 KB file (i.e. sapling).

[fadden]

This should fix the issue: https://github.com/fadden/ciderpress/releases/tag/v4.1.0-d3

I'm always nervous messing with the filesystem stuff, but I threw a bunch of tests at it and nothing seemed to break. Let me know if it does the trick.

[ibrumby]

That's fixed it! Thanks a lot!

[polluks]

@fadden Indeed, good unit tests are your friend.