Feature Request: Make writing case bits optional

[inexorabletash]

Cadius currently always writes the flag bit in directory entries signifying that the volume/file name is (potentially) mixed case in GS/OS (and ProDOS 2.5).

You can't not define the case for filenames with Cadius. A tool that distinguishes these (e.g. by inferring mixed case if the bits are not set, like Apple II DeskTop) would always show Cadius-produced images as SHOUTY.CASE.

It would be nice if there were an option when adding a file to not set the flag bit.

[mach-kernel]

Looks like this is doing it: https://github.com/mach-kernel/cadius/blob/bb38da6c0b425544fdf338130f4ff2254c8845b9/Src/Prodos_Create.c#L127-L130

And the validations for completeness: https://github.com/mach-kernel/cadius/blob/bb38da6c0b425544fdf338130f4ff2254c8845b9/Src/Dc_Prodos.c#L2160-L2183

Will try to get a dent in this over the weekend -- let me know if there's anything else helpful or relevant!

[inexorabletash]

Yeah, looks like making the BuildProdosCase () call optional would do it - ProDOS 8 (not counting 2.5 alpha) would always write those 16 bits as all 0s. So to match a ProDOS 8 produced disk Cadius could write 0s.

On Aug 7, 2019, at 8:30 AM, David Stancu notifications@github.com wrote:

Looks like this is doing it: https://github.com/mach-kernel/cadius/blob/bb38da6c0b425544fdf338130f4ff2254c8845b9/Src/Prodos_Create.c#L127-L130

And the validations for completeness: https://github.com/mach-kernel/cadius/blob/bb38da6c0b425544fdf338130f4ff2254c8845b9/Src/Dc_Prodos.c#L2160-L2183

Will try to get a dent in this over the weekend -- let me know if there's anything else helpful or relevant!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mach-kernel]

@inexorabletash happy holidays! I managed to get this across the line, I think. Can you give #27 a build?

        ./bin/release/cadius ADDFILE       <[2mg|hdv|po]_image_path>   <prodos_folder_path>  <file_path>
        [-C write zeros for name case word]
        Specify a file's type and auxtype by formatting the file name: THING.S16#B30000
        Delimiter must be '#'. Also works with REPLACEFILE, DELETEFILE, etc.
        ----
        ./bin/release/cadius REPLACEFILE   <[2mg|hdv|po]_image_path>   <prodos_folder_path>  <file_path>
        [-C write zeros for name case word]
        You may also specify a different type/auxtype for the file you intend to replace
        (i.e. by changing the suffix)
        ----
        ./bin/release/cadius ADDFOLDER     <[2mg|hdv|po]_image_path>   <prodos_folder_path>  <folder_path>
        [-C write zeros for name case word]

[inexorabletash]

It works, but with three issues, in descending priority order:

• CREATEFOLDER needs the same support added
• The parameter order was not obvious - I initially had --quiet -C which silently fails. As written the parameters need to be in the order: -C --quiet. If the failure was not silent, I would have figured out the problem more quickly (i.e. command-specific flags must precede generic flags)
• A "long form" of the flag would be nice as it's self-documenting in scripts, e.g. "--no-case-bits"

Thanks!

[inexorabletash]

Hmmm... and it looks like CREATEVOLUME needs the same support too.

[mach-kernel]

I took a stab at everything above and updated the branch. I've also changed the catalog functionality to use name_case instead of name for volumes and directories -- if the case word is empty the string remains SHOUTY.CASE for that field, so we can see the changes. To test I would add a directory with a mixed case name and then apply the --no-case-bits flag (to observe it become upcased). The parameter ordering should no longer matter.

[inexorabletash]

Gave it a whirl with my package creation script - worked exactly as expected.

(Note that I only exercised CREATEVOLUME, CREATEFOLDER and ADDFILE)

[mach-kernel]

I don't have a ton of experience with C; what's the best way to go about making a decent test suite? I was thinking the best value for effort would be to script the creation of a volume, copy some fixture files in, use various flags, etc, then sha256sum the resultant disk image. I feel that this is silly, but at the very least if something is severely broken it could be detected.

The right way I suppose would be to use something like cmocka and test everything. Is there value in attempting the former approach or should I bite the bullet and dive into unit testing things?

[inexorabletash]

Reference tests are a good way to start. Either storing the expected checksum or the expected output. Storing the expected output is perhaps better because a diff will show you what changed. So you could have scripts that exercise various operations to construct an image, then CATALOG it, and diff against a reference file.

Unit tests are great but an investment, as you note.