any good prog for archives testing

[lionstorm]

Hi All,
I recently got corrupt archives so I am fearing to have a lot more corrupted files on my HD. So in order to check the integrity of all archives, do you know a good (and maybe fast) program to do the job ?
Lio

[lionstorm]

no good testing programs then ?
Lio

[Varthall]

You could try doing something like this, from the
root directory of your hard drive:

lzx -r t #?

which will test all the archives with an lzx or lha
suffix. The -r option makes the program enter all the subdirectories.

A note of warning: I've read from the faq of lzx -
http://xavprods.free.fr/lzx/index.html
- the following warning:

"The versions for 68020 and 68040 are not so reliable when you want to archive a lot of small files: you may have corrupted datas in the archive. But LZX won't report the bug during the archiving operation. It will report the bug in the test, or on an extraction operation.
Solution : use the 68000 version to archive your files if the 020 or 040 don't work."

So it looks like 0x0 versions have this major bug,
making these versions unreliable!!  :-o

Varthall

[lionstorm]

thanks, I knew about the existance of the test argument of archivers. Problem is I have a lot of files (dms, zip, lha, lzx) in a lot of directories and dont want to check each file manually. I found on aminet checkX but it can not handle zip files. At the moment I am having serious problems with archives : download and test them is ok but transferring them to a zip disk then on my amiga and test them again, they are corrupted. Funny thing is that if I copy them within the WB (3.9) archives are ok, but within dopus magellan, I got corrupted files !??
Lio

[Varthall]

lionstorm wrote:
thanks, I knew about the existance of the test argument of archivers. Problem is I have a lot of files (dms, zip, lha, lzx) in a lot of directories and dont want to check each file manually.

Well, with lzx you can at least test all the lzx and lha archives, and I believe that the same could be done with the command-line unzip, and maybe also dms has some test option. With the wildcards, you'd just have to type three times the commands and let the Amiga do all the checks.

I found on aminet checkX but it can not handle zip files. At the moment I am having serious problems with archives : download and test them is ok but transferring them to a zip disk then on my amiga and test them again, they are corrupted. Funny thing is that if I copy them within the WB (3.9) archives are ok, but within dopus magellan, I got corrupted files !??

So, if I understand well, the files on the zip disk are still ok? Could be that Magellan uses an older unarchiver that the one you use under workbench, which can't handle correctly the archives?

Varthall

[xyth]

What tools or modules are you using to unpack with DOpus?

If you're using XADopus.module this could be the problem.  I've found that it has serious issues handling archives that contain files with names that are too long ( >32 chars ).

[lionstorm]

Indeed I use xadopus ! But archives are usually below 32 char. but files inside are often longer. Anyway it is a long time I have bugs since switching to xadopus but dont know exactly how to remove/replace it. Each time I do a parent on a lister, I am always redirected at the top of the lister (quite annoying when you were at letter x).
Lio
PS : unarchiver is the same since the patch is C:

[lempkee]

use voodoo-X,i use this when i want to extract heaps of files in one go...also it always report errors so...unlike dopus and lha...

shold be on aminet i guess...supposedly still in dev even..

[xyth]

It's the files inside the archives that cause the problem (if this is your problem).

The XAD package (which you should have somewhere in your system if you have XADopus) comes with a very useful shell command 'xadunfile'.

My advice is to use this program to try and unpack the suspect archives, just type something like:

   xadunfile "archive" "dest"

You might have to rename some of the files as they unpack because if they are too long they are simply truncated and this can lead to duplicate names.

If they actually unpack under some name or another then you'll know that XADopus was indeed the problem.