Broken feature in unADF

[OleDave]

I believe I have detected a "new" bug in unADF. It is part of adflib-0.8.0-ubuntu.zip from June 26, 2023. I don't know when it was introduced but it was not present in version 0.7.11a-5 available from the Ubuntu package server.

The -d option for unADF no longer works. It's not just me, the patool archive tool can no longer successfully use unADF.

Issuing the command: unadf '/home/dave/Desktop/Space.adf' -d '/home/dave/Desktop/DumpTarget'

Produces this result: unADF v1.2 : a unzip like for .ADF files, powered by ADFlib (v0.8.0 - 2023-06-26)

Device : Floppy DD. Cylinders = 80, Heads = 2, Sectors = 11. Volumes = 1 Warning <adfReadBootBlock : incorrect checksum 0x444f5300, calculated 0xf4fbf2fb> Volume : Floppy 880 KBytes, "Space" between sectors [0-1759]. OFS. Filled at 1.4%. Warning <adfFileOpen : file "-d" not found.> /home/dave/Desktop/Space.adf: can't find file -d in volume /home/dave/Desktop/Space.adf: can't find directory /home in volume

This is not critical issue. Using unADF without the -d option will successfully extract the disk image into the current directory.

[lclevy]

Could you please provide the related adf ?

[OleDave]

See attached. It's the same one I sent to your personal email yesterday. Note that I've gotten the same behavior with another adf as well as an hdf.

On 12/6/2023 at 1:01 PM, "Laurent Clévy" wrote: Could you please provide the related adf ?

—

Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: --=_2a9e498b7643045dc981d4344ee3e8e6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

<span style=3D"font-family: Arial; font-size: 14px; line-height: 150%;">See attached.  It's the same one I sent to your personal email yeste= rday.  Note that I've gotten the same behavior with another adf as wel= l as an hdf.

[t-w]

@OleDave, it seems to me that you have provided the arguments in an unexpected order - normally the argument order for unadf is:

unadf [-lrcsmpw] [-v n] [-d extractdir] dumpname.adf [files-with-path]

After the filename of an adf dump, a list of files to extract from it can be provided (see the man page for details). That is why you got the:

Warning <adfFileOpen : file "-d" not found.>

Try running your example reordered as follows:

unadf -d '/home/dave/Desktop/DumpTarget' '/home/dave/Desktop/Space.adf'

(assuming that you want to extract the files to /home/dave/Desktop/DumpTarget directory - because that will be done by this command).

[t-w]

btw - sending files via email to github is not the best idea... so maybe you can have a look how it can be done properly

[OleDave]

Space.zip Space.zip contains Space.adf, the file I had intended to attach via email.

[OleDave]

Here is a snippet from the built in help from unadf version 0.7.11a-5: unadf [-lrcsp -v n] dumpname.adf [files-with-path] [-d extractdir]

Here is a snippet from the built in help from unadf that is part of adflib-0.8.0-ubuntu.zip from June 26, 2023: unadf [-lrcsmpw] [-v n] [-d extractdir] dumpname.adf [files-with-path]

I simply overlooked the change. Using the new command line order as you suggested above works perfectly. I am pleased to say that unADF meets my needs.

That may not be true for the wider audience: There is an extraction tool called patool: https://wummel.github.io/patool/ That uses unADF as a helper application. The command line change breaks patool.

Personally I think the new command line is more logical and I would be happy to consider this (non)issue resolved.

Thank you for your help and guidance.

[t-w]

Well, I see that the change in the unadf's parameters order was done (4ce14b2) already for the version 0.7.12 (archived in the repo), so this is not something new in 0.8.0... I haven't even known about the adflib before that so I have no clue what drove earlier changes, but I am sure that @kyz, who made that change doing a rewrite of the tool, must have had good reason to do it. patool will have to adapt (if haven't done this already...), not a big deal as you see...