it would not tell us if we got a good copy on the destination folder.
What good is a validity check if it would allow for a bad copy to the destination?
if we say we are verifying files then we must check it again after the copy too...

this is my point - do it right or dont do it

i really don't see the point in doing it when it will cost me an extra five minutes every run and i have yet to have a bad pack in three years. so it will cost me five minutes every run and once in one hundred runs will i have a bad file.

so i waste 500 minutes (one 8 hour day) on the off chance i will burn one bad disk in three years.
i consider this a huge waste of time - if you cant figure out you have a bad file on your own you need a new job...

PS if you always test in a VM first then you test ALL (not just DriverPacks) the files at one time

you have make nothing automatic.
and you can test it by yourself

I just wrote a script for you guys so you can check them at any time...

Very clever script...I like it!

Just to clarify though, what I meant by "check once" was a check where say a DP is scanned, and then an entry made in the INI so it isn't checked again later.  But if someone is having problems with corrupt files that probably wouldn't do any good.

I assume by your x2 comment that you would check before and after integration, but probably just a check afterwards would do.  Whatever

I thought the idea of a "check once" sounded good, but really I think if you're having problems with corrupt files that the "check once" won't be much better than a check every time.

I personally don't see the need for it, but it's very simple to implement and could be optional so it might be worth a try.

I did a quick test on this machine (2ghz), and it took 8 seconds to do a  7z.exe t *.7z on LAN/WLAN/Chipset/MassS

yeah... if it really only added 30 seconds (to check it twice) it would be more appealing...

however, i just ran my script above on just the 10 main packs and it took 1min 45sec x 2 = 3.5 minutes
so currently i can slipstream a m2 install in about 5 min so almost twice as long to run base as normal
And more than twice as long if i have third party DriverPacks too. (run on a P4 2.8 HT)

I personally would like it to take less time than 5 minutes
and each time i update base i do look for ways to streamline the code towards that end.
if the archive checks are implemented then making the check optional is guaranteed.

As a programmer i can not assume. If i am going to do validity checks then I will do them well. no sense in doing it poorly. If I say we are validating the files then I must do a Source and then a Destination check and I must do it every time (unless this option were disabled by a GUI check-box which would default to enabled)

it was PEBKAC the above code works based on the errorlevel setting
( I initially tried to cram it all into one line of code - and it turned out i needed a subroutine )

Agreed, good point

sounds impossible to me.
it is like a re-iteration?

Suppose you have a 7z file, you calculate its hash, then write that hash as txtfile (or whatever, with standardised naming) and include the hash in the new 7zip, with a new extention (BTX), so that the DriverPacks BASE has to unpack hash and real DP, check hash txt against file hash..

No, that's not what I meant.
The TXT is not supposed to be included in the 7z file - that one is not to be altered at all (that would defy the point of calculating a hash that is supposed to verify the file is unaltered...)

I was thinking more along a list in the TXT that goes like this

NAME_of_DP             Hash of that DP
Name_of_next_DP     Hash of next DP

Anyway, whatever, just a little brain quirk, nothing more.
Not even considering whether it's doable...

Hehe, I knowthis was coming and I fully understand you.
I was just speculating about how it could be done, if at all.
Not saying it is feasable or anything.
Also, as I said, this was under some premises of which I did not know whether they were true or not.
If 7z does not return a succsessful/error code then it won't work I guess.

Well, that's up to the bruning program to test/verify (file on disc=file on HDD).
Nero, for instance, has such an option and I make regular use of it for reasons already known.
Basically, each app in the process has to test for its own area of competence - in an ideal world, at least

should i offer a third choice...  "let me see your CD/DVD after you burn it so i can check them again?"
IE what happens if it gets corrupted after base is run? (like during the burn process)

since base copies them to a destination folder i guess i would have to check them twice before and after the copy?
at what point can we agree that corrupt files are rare and wasting time doing checks multiple times on every run is silly...
furthermore i often just substitute one pack for another and don't even run base. what about people like me?
I just don't see a ROI on this... if you guys do then i will concede

I am sorry, there is no way for us to verify files. it is up to the user, especially since the files are copied and burned after base is run. the only way it can be made to be reliable is if i add the feature to burn a disk from base. at that point then i can do an integrity check from 7zip before and after the burn.  This way is the only way that a test would be valid or useful.

edit..............

I just wrote a script for you guys so you can check them at any time...

@echo off & color 1f & Cls & ECHO. & ECHO.
rem last edit 2:10 PM 7/13/2008 - Author Overflow - FileName  Verify.cmd
Title 7Zip Archive tester

:Input
echo Cut and Paste the path to the 7-zip files you would like to have validated & echo.
call SET /P SourceFiles=Path? & echo.
SET _result=%SourceFiles:~-1% & IF [%_result%]==[\] Set SourceFiles=%SourceFiles:~0,-1%
IF Exist "%SourceFiles%\*.7z" goto Test
echo Are you sure the 7-zip archives are in that folder? 
goto Input

:Test
FOR %%i IN (%SourceFiles%\*.7z) DO call :Sub1 %%i
goto exit

:Sub1
7z t "%1" > nul
IF %errorlevel%==0 echo %1 	Passed Integrity check
IF NOT %errorlevel%==0 color cf & echo. & echo %1 Failed Integrity check & echo.
goto :eof

:exit
echo Testing complete & pause

if you run the script above from the bin folder in base (where 7z.exe is) it will report a bad archive and turns the window red.

Sorry this will not be a feature unless we also add burning as a feature - file validity checking is up to the user.

I will continue to think about this idea and how it may be grown into something effective and useful

PS M1 will report a bad archive every time

Okiedokie...I will think about that

I use Winrar because I easily can make installers.
And that succeeds me not yet with 7zip. (if you have tips for that then gladly)
Only if I adapt a driverpack I use 7zip.

and then happens the same....as Winrar.
if a unpack this broken/wrong pack.

I personally don't see the need for it, but it's very simple to implement and could be optional so it might be worth a try.

I did a quick test on this machine (2ghz), and it took 8 seconds to do a  7z.exe t *.7z on LAN/WLAN/Chipset/MassS

we have a Dutch language forum.
Real important problems will get escalated and translated. I think you can explain what happened in our native Dutch language a lot better.

7zip is freeware.
Winrar (last time I looked it was not free..) is not needed, and may have introduced an "unknown" error.
Actually, you only need to uncompress when you want to edit the DriverPacks.

Far as I know, you can not include the hash in the archive, because the hash is calculated after the archive was made.
(which made me write the daft suggestion to make the DriverPacks, calculate the hash, pack the DriverPacks with the hash info into a new file, and give it a new extention (not an archive extention) so that base 'could' unpack the BTX "zip" wich included the hash txtfile and then read the content of the hash/compare to hash of the real 7z of the DriverPacks... and, actually, nobody could guarantee that THAT hash was not tampered with.. If you were to modify your own dp and did this yourself... The hash we post online cannot be tampered with unless you hack the site. We post the size, the hash, and have always allowed users to modify their DriverPacks because advanced users can/and will. We rely on advanced users to solve issues with driver conflicts.)

(A re-iteration is something else.. I used the word because it was the first that came to mind.)

Suppose you have a 7z file, you calculate its hash, then write that hash as txtfile (or whatever, with standardised naming) and include the hash in the new 7zip, with a new extention (BTX), so that the DriverPacks BASE has to unpack hash and real DP, check hash txt against file hash..

huh?
pop a warning when the file was edited by user..

I have nothing against posting the hash, but I think coding strict file hash safety in DriverPacks BASE is not easy.