ADFCHK - Amiga DOS Amiga Disk File Checker

[andreas]

Yes, thanks, that's how I like it!

To a more serious note, I simply have to fiddle with the waitKey() procedure to get this working on Linux. I hope I get my Cygwin up and running today, so I can investigate this bit more. Maybe I should really get rid of stricmp() and instead strcmp() strings that were previously converted to all-lowercase or all-uppercase.

Does the same thing and is lots more compatible.

[haps]

Please disregard my old patch, it is crap! Blame it on a lack of caffeine.

The shared library was not linked in properly. I have it linking properly now and also looking for the library in the proper system directories (as well as same dir as binary). It is working on some disks, however I am getting core dumps with free() pointing to wrong pages on others. I have also revised the build system. I will be able to provide a working patchset later today or tomorrow (it's going to be a hot day and the pub is calling out to me ).

[haps]

Here is the revised patchset. The zipfile contains a directory named bsd that goes in the root directory of the source tree. It contains a configure script that will create a backup of the original makefile and replace it with my one and patch the source files. It also copies a makefile into the src directory. The main makefile compiles liteunzip and then does make in the src dir which compiles adfchk against the library. The clean target returns the source to it's original state bar the patched files. The original unpatched source files are in the source dir as file.orig

EDIT: patchset removed. No longer valid.


Everything seems to be working fine except for the following problems:

When I scan the Turrican II source [89BC0C2A] that was in the zone recently, it can scan the unzipped adf fine. However when I scan a zipped copy I get the following error

free(): error: free_pages: pointer to wrong page

On windows it just gives an 'Invalid Amiga Disk File' error. Could one of the linux people test this? I will compile with debugging symbols later and see if I can trace the problem.


When I scan 'X-Copy Professional & Cyclone v10.3 (1992)(Cachet).zip' [7272F8A9]

It tells me the zipped copy is a non-bootable NDOS disk immediately, while with the unzipped copy it reads the sectors successfully but then tells me the same thing when I choose option 4. On windows with the zipped version, I get a message saying it is a bootable disk immediately and with the unzipped version it scans the sectors correctly and then option 4 tells me that it is a bootable disk.

The processing volume text is shifted all the way to the right when scanning disks as the following screenshot shows. This happens on both nix and windows.



I will run some more images through it later and report any problems.

[andreas]

Originally Posted by haps

The processing volume text is shifted all the way to the right when scanning disks as the following screenshot shows. This happens on both nix and windows.

Oh, actually this is purpose.
It actually looks quite good with a very small but readable font here on the DOS console.
I thought (!) that it's better to have the volume names on the right than mingled with the other text rattling down the screen in multi-file batch mode ... but maybe that was a wrong thought...

BTW, Cygwin is running fine here now.
#error does NOT seem accepted by cygwin gcc!

I knew quite well why I decided to comment that out. When I comment that out in typedefs.h, it works.
Maybe that is GCC 3 only? I'm using v4.

In file included from adfstruct.h:8,
                 from adffile.h:13,
                 from adffile.c:5:
typedefs.h:50:2: error: #error It just does not work.

OK I managed to figure out what the problem is!

It's the macro xformHton*() and xformNtoh*() family. These are used for my getSecData* group of functions, and they were always zero!
This will make the BAM key to "invalid" (-1), no wonder that your disks were recognized wrongly!

Not that it calculates wrongly, at least in Cygwin there seems to be a BUG!!

This will make it work:

#ifdef __CYGWIN__
#undef BIG_ENDIAN
#else
#ifndef LITTLE_ENDIAN
#define LITTLE_ENDIAN
#endif
#endif

plus move that xform* stuff into adffile.h, otherwise we would have to #include typedefs.h which often creates new linking problems.
Totally crazy! Why do I have to manually #undef BIG_ENDIAN when LITTLE_ENDIAN is defined? Maybe I should report to the list with a small test program.

0.1.4alpha attached, source only.

On native Linux, it might even be necessary to include <endian.h>. If you really can be arsed to debug around a bit, then please check getSingleSecDataLong() which returns single long words of all that precious block data.
If it's zero, *NONE* of the macros are chosen. I've just hacked in a short printf() in either of those and got nil. Until I #undef'd BIG_ENDIAN for fun's sake ...

[OddbOd]

There's still an unconditional stricmp in adfmain.c line 271.

Originally Posted by andreas

#error does NOT seem accepted by cygwin gcc!

Your syntax is wrong, read the cpp docs for correct usage.

Originally Posted by andreas

OK I managed to figure out what the problem is!

I don't think you have as this is not Cygwin specific.

The problem is your endianness checking, BIG_ENDIAN and LITTLE_ENDIAN are not check values for you to run comparisons against, that is what BYTE_ORDER (from endian.h) is for. What you've actually been doing is changing the meaning of the ENDIAN macros then checking against your own redefinitions. This code should point you in the right direction.

[andreas]

I don't think you have

Oh yes I have! For I have found out that my macros were not touched at all and also know why I always got zeroes when fetching long words ... so I got the cause of the problem, that's why I said "I figured it out".

Originally Posted by OddbOd

Your syntax is wrong, read the cpp docs for correct usage.

Thanks, but none the wiser, as also with the #error-text in " " it does not work here. Strange...

The problem is your endianness checking, BIG_ENDIAN and LITTLE_ENDIAN are not check values for you to run comparisons against, that is what BYTE_ORDER (from endian.h) is for.

Hold on. I do know about BYTE_ORDER, but this is *NIX-only. That's why it works on Windows.

This code should point you in the right direction.

Yes, this could help a lot.
Thanks so far.

[OddbOd]

I know you figured it out, the previous comment was not intended to be an insult but a counter to your assertion that Cygwin/gcc was the cause, which it wasn't. The error directive remains a mystery then, it works fine for me with both gcc 3 and 4.

Let's not worry about that stuff now because it works!!!

[andreas]

Indeed it does.
I will just ignore the #error directive thing for now and merge the working source into a new package.

Thanks for all the good eyes to both of you. It proves again that for developing for Linux, it is NEVER sufficient to have only Cygwin; it is always mandatory to have this tested on a native Linux system.

ok, package merge coming up...

@haps:
On Cygwin here, your makefile only works if LiteUnzip directory is found!
Otherwise I get an infinite loop, which - on Cygwin - was bloody hard to interrupt, if not to say, by hacking CTRL-C like a madman.

[BippyM]

The program stops for a non-adf file. Can this be changed so it outputs all errors to a secondary log file?

I can't be bothered to press enter for 5000+dms images in the path

[andreas]

Uhh...it does this with DMS files too?
It was actually meant to only stop with corrupt ADFs.

Yes, I should look into this.
I could not find out about this bug, since I have my DMSes and ADFs separated, so I got three requests to press enter, which were a good idea because I could move them out of the way easily right after detection.

Indeed I will have to use TWO log files then.

For you LINUXers and BSD guys:
Updated source archive (v0.1.3bis) is now available on the first post.

[mr_0rga5m]

adfchk v0.1.2 RC2 by A. Eibach (c) 2007 - 2009 .. Has Germany already crossed the dateline to next year.

[andreas]

No, just laziness (Toni would do this the same way I'm sure ) because it's easily forgotten to bump up the current (c) year. And we have almost 2009, so ...

btw, get the new build, orgasm
the one you quoted is buggy as hell

[haps]

Originally Posted by andreas

Oh, actually this is purpose.
It actually looks quite good with a very small but readable font here on the DOS console.
I thought (!) that it's better to have the volume names on the right than mingled with the other text rattling down the screen in multi-file batch mode ... but maybe that was a wrong thought...

On an 80 column console it means the text wraps. Maybe you could shift it to the left by 10 or 15 to avoid the wrapping?

[Edit] Disregard that, it was the screen program that had resized my putty window.

Originally Posted by andreas

@haps:
On Cygwin here, your makefile only works if LiteUnzip directory is found!
Otherwise I get an infinite loop, which - on Cygwin - was bloody hard to interrupt, if not to say, by hacking CTRL-C like a madman.

I'm pretty busy today, because my old arsehole of a lodger is moving out (thank god, he has been nought but trouble since he moved in) and my mates son is moving in.

I have downloaded the new sources and will have a look in cygwin if I get the chance. I will try and get a linux machine up and running as well so that I get the makefile working there. The bsd make is a little different from gnu make and I would rather avoid any gnuisms so that there is no need to install the gmake port to build on bsd. I should be able to get a universal makefile happening though.

[Photon]

Sound nice andreas Will tip off Richard, seems he has not yet discovered this.

[andreas]

OK, do that then

[haps]

While having a beer and a smoke after lunch, I remembered that the BSD make will look for a file called BSDmakefile before using Makefile/makefile. So the following zip takes care of building the app on BSD.

bsd-makefiles.zip

I might see how it goes compiling on Solaris later if I get the time.

[andreas]

0.1.4 is out!

Now detects:
overdumps / underdumps, extended adfs (2 formats; no scanning yet due to MFM architecture)
log files in mass-batch mode are now appended a suffix according to result (_OK, _ERR, _VIRUS etc.)

"Fixes":
Deep data-block checking. In ADOS, data blocks are the only ones known to me that do not use a secondary type for reliable "does / does not meet type characteristics" determination. Not every block that has a $00000008 at the beginning is necessarily a data block but could as well be coincidental from alien format

And especially for Bippy:
No keypressing anymore. Should be able to scan fully unattended now.

[BippyM]

Originally Posted by andreas

And especially for Bippy:
No keypressing anymore. Should be able to scan fully unattended now.

WoOOooooo Will test over the weekend

[Ian]

Good little app Andreas.

I have some suggestions if you are open to them.

Only create a log for a bad adf with the log having the same name as the original adf and rename that adf/zip with a prefix ZZZ-BAD or something similar to find the bad ones easier.

[andreas]

Originally Posted by Ian

Good little app Andreas.

Thanks Ian, fellow EAB veteran! (uid=82)
(I had no idea I'm an error code, since my user ID is 121 )

I have some suggestions if you are open to them.

Yes, of course.

Only create a log for a bad adf with the log having the same name as the original adf and rename that adf/zip with a prefix ZZZ-BAD or something similar to find the bad ones easier.

No.
At least not by THAT way. Many users would get upset if I re-rename their files already correctly renamed using the TOSEC DAT.
There is an alternative to it, though. A future version should be able to MOVE these files to a "bad" folder anyway. In this early version, where most is batch-controlled, it could also help to catch a special return code by the .BAT, so the bat can act accordingly. I still need to figure out whether this is actually possible or not.
But collecting them physically in a "bad" folder is a good idea, unlike renaming them, which I would have to make optional again to begin with, etc.