ADFCHK - Amiga DOS Amiga Disk File Checker

[andreas]

Hi everybody,

finally it's FINISHED! Or better: the first USABLE version is completed.

This is a small tool I've written thoughout the last few weeks (mainly) - started somewhere in 2007 though - and I'm happy to make it available to everybody.

You can check for checksum errors on blocks with ADFs, detect LAMER viruses on block ("boot-Lamer" is in the works) and more. You will also not get bogus "Checksum error!!" alarm with blocks marked as "free" in the bitmap. The invalid checksum will be noted in the log, but won't appear in capitals.

Note: LiteUnzip.dll must also be in path where the executable is!

I have not yet tested the app on Linux, but I think I provided everything (also the LiteUnzip.lib) with which you should be able to build my app on Linux. Feedback on this is greatly appreciated.

In 99.9% of cases, you will want to use the tool in BATCH mode, because menu mode is still very limited, not even speaking of the absence of a GUI. But well, that's just why version numbers have been kept deliberately low (v0.x.y-RCi)
For batch mode operation, three VERY nifty complex .BAT files (which took me days to debug and write) are included, which can start a HUGE scanning process for thousands of files. I've scanned 4,000 files today in one run with a hell of subdirectories, and no problems occurred!

OK - so enjoy it, and I hope you can make some use of it!
I have one huge aim: my tool should make it possible to figure out THOUSANDS of ADOS images in TOSEC which have undiscovered checksum errors! This might prevent frustration among gamers who gave everything to reach level 9 then it crashes!

Source is provided - however, you should only download it if you're a developer or want to build the app on linux! The rest (using Windows) will be happy with the binary release!

---------
[andreas]
---------

[edit] Please see this new thread for the new branch (0.2.X)

[EvilCensor]

Taking a look now!

This sounds like a pretty useful tool and without doubt your "huge aim" is definately an honourable one.. many thanks.

Will leave some feedback once tried properly.

[BippyM]

Nice app andreas will test soon

When you add full batch mode (unattended with logging ) it may just be perfect

[andreas]

Well, as long as no severe errors occur, this thing MAY run half an hour or one full hour for thousands of images.
The .bat files work well on Windows, and also helped me to not delay the release until next year because true recursion *within* the app is no 5-minute job.

BTW, if you really DO want one log file with probably hundreds of megabytes, you can run

CHKALL.BAT 1>output.log

or also redirect the error output by

CHKALL.BAT 2>output.log

Currently I'm using by-file logging, which probably puts 1000's of log files into the \logs\ folder, BUT can be read with any editor, or better, viewer.
Another good idea would be to fire lots of those logs to a good multi-file capable ASCII text viewer and then simply browse through all the information.

[TCD]

Nice one andreas Tried it with some disks and the log is simple, but has all necessary infos (luckily I found no bad disks so far ).

Originally Posted by andreas

The .bat files work well on Windows, and also helped me to not delay the release until next year because true recursion *within* the app is no 5-minute job.

If you plan the use of recursion in the app right, it's actually easier (or not much more to code than without it). Hope you get it sorted soon, so that there will be an option to scan a folder with all subfolders at once making one huge log file like bippy said

[andreas]

Tried it with some disks and the log is simple, but has all necessary infos

Yup. No "prose" in log files, that's a must. BTW, logs will be much better once the directory tree structure is working, though, because then I'll bit-mask the whole disk with TRUE for blocks used by files, and FALSE for blocks not used by files. Caution: blocks marked as USED in the Bit Allocation Map (BAM) do NOT necessarily have to contain vital data and can as well contain random data without causing any harm! Currently, my app is in strict mode and will also detect them as checksum errors. Next version will distinguish block types, though This means, block type = UNKNOWN and checksum error won't necessarily stand for corruption!

If you plan the use of recursion in the app right, it's actually easier

Not really. Not with the goal of making the app run on both Windows and Linux at least.
Directory handling is COMPLETELY different in Windows and Linux, and, to my knowledge, requires completely separate functions to use.
Hence, the first step on the *NIX world will be a bash shell script (chkadf.sh).

Well to accumulate everything in ONE log file can be made optional, no problem. To meet everyone's needs, I'm just going to include three more BAT files which use ONE log file for everything.

However, personally the by-file solution is not that bad, because you can simply even use Windows search for 'OK' or 'unreadable' and move away all logs for files with no errors or unreadable bitmaps, only leaving the ones to be checked.
It would also possible to tag the single log files so they can be filtered more easily. Maybe...

So my plan is this:
- add an alternative batch file which will always specify the SAME log file name, which by an INTERNAL (?) option will NOT ask if the file should be overwritten; however, I need to confirm the overwriting of the log file by default when the app is not invoked from a script.
Tricky, but I think it can be done.

[EDIT] There is one limitation I can't do much about it at this early stage: Files with characters like '%' (percent signs), which are interpreted as variable placeholders by the BAT processor CANNOT be processed, so make sure to either move them out of the way before scanning or rename them so that the filename does no longer include a percent sign!

[OddbOd]

Hi andreas, I decided to try building under Linux and came across a few minor problems, the attachment is a modified source package including a basic Makefile that I used to compile adfchk under Gentoo.

stricmp() doesn't seem to exist so I swapped it for strcasecmp(), this probably doesn't work under win32, you could change the source to use strcmp()/toupper() or provide your own stricmp() to avoid this problem. Could you please add a switch that will force interactive mode when -f is used, the hardcoded name makes it quite tedious to test different ADFs.

Keep up the good work.

[andreas]

Thanks a lot for your work!
Well, thanks for reporting that stricmp() does not exist (I had no idea), so I will simply hack an #ifdef in and this should do the trick.

Could you please add a switch that will force interactive mode when -f is used, the hardcoded name makes it quite tedious to test different ADFs.

Hmm, originally -f was designed to only have one file, but indeed, I could add another option for batch mode and default to menu mode. This will require me to rewrite the ENTIRE command-line parser, though. Ugh.
But sorry, no WILDCARD support for now if you thought of that! Functions reading Windows directories is still something I have to delve into.

Another preliminary solution on your Linux OS could be a shell script. Since you contributed the Makefile for me, the shell script is, of course, higher on the TODO list now.

BTW: I've also seen that you moved the LiteUnzip.h from zipsupp/ into the main directory.
I'd actually liked to keep them separate (as it's not my code) but would this cause problems when MAKE'ing the app? Well, I think you must have had a reason why you moved it, obviously ...

[Charlie]

Thank's very much for your hard work.

[hit]

i also tried compiling on a linux box. some problem (rc2):

1) adfmyunzip.c: line 80: if (!(destbuf2 = malloc(sizeof(dskImgS_t))))
missing a ")" at the end of line
2) replaced all "stricmp" with "strcmp" in adfmain.c
3) moved LiteUnzip folder and LiteUnzip.h into the src folder
4) editing includes vor "LiteUnzip.h"

seems working this way. the compiler shouts about "gets":
adfmenu.c: warning: the `gets' function is dangerous and should not be used.

thanks for the tool

[andreas]

And to you: thanks for the FEEDBACK! Compared to the "riot" when I first released my app, it seems to have been bit quiet in here since then.
Whatever, here's 0.1.3!

---------------
NEW SINCE RC2:
---------------
- supports block types (file list, header, user directory, formatted, unknown...)
- standard type recognition works now (FFS + INTL/NO INTL, DIRCACHE etc.)
- FFS detection support (it makes no sense to check FFS disks for "checksum errors", since FFS does not use checksums for data blocks)
- fixed lots of misdetections and phony reports of "checksum errors"
- stricmp() replacement for Linux users (now uses strcasecmp())
- LiteUnzip.h in its own folder seems to have confused tools used on Linux to build the app - now in src/
- lots of minor tweaks, code cleanups and fixes.

FEEDBACK PLEASE!

(attachment on first post)

[haps]

The following patch allows it to compile on OpenBSD. The makefile includes install and uninstall targets and copies LiteUnzip.h into the linux directory seeing as the LiteUnzip makefile expects it to be there. It should also work on the other BSDs. I only tested the app quickly on a couple of adfs, but I will have a proper look when I have some time, I can also make some shell scripts for it if no-one has done so by then.

To apply, unzip, copy the patch into the root directy of the archive and say 'patch < bsd.patch'



EDIT: Removed patch. It was seriously flawed due to a lack of caffine, tobacco and herbs!

[andreas]

Thank you!

I only tested the app quickly on a couple of adfs, but I will have a proper look when I have some time

Good. There is nothing more valuable than FEEDBACK. Developing for an all-time quiet audience is not real fun

However, can you please tell me why you REMOVED stricmp() in the Win32 build?
It works there.

if (!(destbuf2 = malloc(sizeof(dskImgS_t)))

Please do NOT patch such things!
This is a typo of mine!, and it's MY job to fix these!
Refresh release will come immediately!
[edit]done.

[haps]

Originally Posted by andreas

Thank you!
However, can you please tell me why you REMOVED stricmp() in the Win32 build?
It works there.

Woops. I just did a global search and replace, I will fix this.

Originally Posted by andreas

if (!(destbuf2 = malloc(sizeof(dskImgS_t)))

Please do NOT patch such things!
This is a typo of mine!, and it's MY job to fix these!
Refresh release will come immediately!
[edit]done.

True. Will also fix.

EDIT: new patch attached to previous post.

[andreas]

Originally Posted by haps

EDIT: new patch attached to previous post.

This looks like the same patch (08/11/18, 01:39)
I cleared my cache, downloaded everything again - same thing.
Are you sure you uploaded the right (updated) one?
I can still see those parenthesis fixes ...

[haps]

Originally Posted by andreas

This looks like the same patch (08/11/18, 01:39)
I cleared my cache, downloaded everything again - same thing.
Are you sure you uploaded the right (updated) one?

Noticed that myself when I read the patch from my windows machine. Had to disconect the samba share and reconnect to get the new one. Should be good to go now.

[andreas]

Yes, now it's excellent! Thanks for the new patch.

[OddbOd]

Thanks for the patches haps, they're cygwin friendly as well

The reason I hadn't posted back is because the program simply doesn't work on anything other than Windows and so far I haven't had time to figure out why. All I can say at this point is the ADF is read into the buffer correctly (tested it by writing the buffer back to disk) but after that everything goes wrong. I should have time tomorrow to have a better look at what's going on.

Example:

---------------------------------------------------------------------------
CHECKING DISK:          'Workbench v1.3 rev 34.20 (1988)(Commodore)(A500-A2000)(Dk)(Disk 1 of 2)(Workbench).adf'

PATH TO FILE:           '.\ (current directory)'

BOOTBLOCK TYPE:         'DOS0-OFS'

AMIGA DOS VOLUME NAME:  <not available> (illegal length - NDOS disk?)
Found no address greater than 0x00000000 to jump in the boot program - this disk is not bootable.

Neither a valid BAM key nor valid BAM data found on disk.
This disk appears to be a non-bootable NDOS disk, probably a data disk.

---------------------------------------------------------------------------


This disk is OK - there were no errors found!

[andreas]

Urgh. I don't like the line of Volume name "not available". This line *IS* valid for NDOS disks, though, as those do not have a volume name @ offset $6E1B1 ff.

BTW, I really had no idea that there is such a high acceptance for Linux!!
I had just been in the mood of including parts to build the app on linux, but had no idea such a number of users would even DO this!

So I should really keep moving and get me the latest Cygwin to have a Unix-like environment and finally debug this! Thanks everybody for the reports.

[hit]

for the linux compile, i had to fix (again):
1) moved linux/LiteUnzip and Makefile into src
2) editing adfmain.c (three stricmp -> strcmp)
3) editing typedefs.h:
#error (TODO: Error handling will happen later.) /* error */ /* TODO */
into
#define error (TODO: Error handling will happen later.) /* error */ /* TODO */

Edit: (3) doesnt really work it seems, instantly "Press RETURN to continue ..." appears, and not going back to mainmenu or quits. no result written, just this line and the "about box".

just some feedback, as requested