i am thinking that if i were to put in a gui switch it would need to be source and dest as the checkboxes.
in this way one might select none, one, or both...

Your efforts are appreciated
thanks for helping make DriverPacks better

so that would prove that the file was good (or not) before we use it.

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 wink

That sounds like a great plan!

ophielx wrote:

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. wink

well if we continue with our premise, saying that we will validate the packs, we can not assume that they are still good even though they were good the last time. wink

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)

Helmi wrote:

Hehe, I knew this was coming and I fully understand you.
I was just speculating about how it could be done, if at all.
Not saying it is feasible 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 successful/error code then it won't work I guess.

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 wink )

Helmi wrote:

Well, that's up to the burning program to test/verify (file on disc=file on HDD).

Agreed, good point

I put a big scull and cross bones on my full unattended LOL wink
Really... i do this in big fat red felt tip!

and a note like "This disk will automaticaly WIPE CLEAN the primary HDD"

bump edited my last and cross posted with you Helmi

well it is certainly a lot more appealing to me personally as an option (waste my time / or not)

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 wink

that was more clear... thank you.

Corrupt file detection has been discussed. There is not an obvious way to confirm if the files are valid. The DriverPacks base does not open the files it only copies them. since the packs are never accessed there is no indication of any problem.

the biggest obstacle is that the files will not get extracted until they are being used for the first install.
if we were to force a verify into the base process it would add a considerable amount of time to every run of the program.
however bad copies are few and far between.

It is better to just to be aware that a bad copy can happen... always make a backup wink

The oem dell disk includes drivers, branding, machine checks and bundled software.

IE it is not a clean starting point.

I would investigate the contents of their $oem$ folder and other locations for bundled software and drivers that might conflict with DriverPacks.

you could work backwards and split the packs in half say skipping graphics and sound packs first go around
if the problem is gone it is resonable to assume we are looking for a sound or video driver that is confilcting
by process of elimination you could probably narrow your search to a specific pack that is at issue. this will help focus your search for the problem with the OEM disk

i second that
lets see presetup.cmd too... i suspect it has been altered

no... we provide file sizes and md5 hash values so you can verify the files.

please verify your downloads to avoid this problem in the future

Welcome to DriverPacks

1 IDK...
2 method 2
3 No... there are registry entries and cache files that need to be added when the folder is populated.

Welcome to the group sir!

each pack has a changelog and a DEVICE list available from the overview page.
since this is a laptop then you may want some of the packs from the 3rd party DriverPack section / forum too. (modem, ect...)

we take a different approach than waht you are expecting. we add all the packs then 99% of all existing drivers are available.
So it will work on ANY machine. if you find a driver that is not included just grab the HWID tool that is in all of our signatures and post that with as a [REQ]uest and we will add it (that is how we get to, and maintain, that 99%)

best bet is to get all the main packs and just the 3rd party DriverPack that you think you will need then make a test UXP disk and test it
verify your backup or ability to restore vista just in case. Idealy you would have a second HDD for this, but i understand if not.

Laptops are often dificult - if the OEM doesnt offer xp drivers - sometimes we can still help but often it comes down to you being able to tell us what works or does not work.

Thanks and have a great day

yes it pops up a nag screen yes/no

we use the DriverPacks finisher to monitor those registry entries while it runs...
did you not read what i wrote or do you just think i am stupid?
or was the statement "(they aren't registry entries, they are windows setup parameters /  switches)" somehow unclear?

please don't 'Guess' when i have given you the answer already.
(I did not have to guess i already knew the answer)
um this is your first day and you think you can suddenly find some secret that this team of people who have spent years doing this missed?

sorry... i get a liitle terse when my cage is rattled wink

why dont you experiment with it a little and after you are familiar with the basics we will do a Q&A again if need be.
I think you will find almost anything you want to know is already covered here somewhere. ( search feature wink )

Welcome to DriverPacks

we need your HWID's at minimum to accomodate you.

please read "read BEFORE you post" in my signature -
it outlines the minimum info we need for every post includeing [REQ]ests.

It would be nice to know wich base and pack version you were useing that did not work.
(the latest is not an acceptable answer since we have many of those)

update your post and its title with the missing info and we will se what we can do.

have a great day

i would recomend setupmgr not be used in favor of nlite... that will help you get the last few hiccups out of your unattended.

Welcome to DriverPacks Dan

if you want all your files in $OEM$ you will have to switch to method one.

Method one is considered obsolete. it has a path limitation of 4096 characters which we exceeded long ago.
it also cab compresses the files which takes up a larger amount of disk space (7zip=300meg - cab=500meg)
it takes a few hours to extract and them cab them the first time (with QSC=ON you will not have to cab them a second time).
This also causes windows setup to copy the drivers during textmode and is quite a bit slower than copying them during winpe.
   but... this would put all your files in the $OEM$ folder.

with method two the drivers are put in OEM because we don't want them copied during textmode, so they are not in $OEM$.

I would respectfully suggest you not fool with it and just accept the new OEM folder we create... its the best solution and has been in use for years and tested by thousands of users - (if it ain't broke don't fix it).

if you remove the entries from winnt.sif then the install may hang asking about unsigned drivers...
if you are not doing an unattended install this is probably not a big deal since ther are only a handfull of drivers that we know of that need these entries - and even that handful will only gripe if the hardware is actualy present in the system.
(since it's an 'attended' install you are expecting it to stop for user input anyway what is one more dialog box when your doing a repair?...)
these entries can not be created by any other method. (they aren't registry entries, they are windows setup parameters /  switches)

no third party are kept track of too. (base creates a txt file that contains the original name when it renames them during the slipstream) wink

This absolutely won't work with M1 because presetup.cmd is not used -
jaak is correct this will not work with M1 -  but m1 is not very popular anymore either so it is only a minor flaw.

I think you misunderstoood...

re  DPsXtrct.ini.

would not be required DriverPacks has a routine that converts the 8.3 names back into thier full names so  DPsXtrct.ini is not needed as it can be replaced by a built in process. (no manual file edits)

sp3 is working for all of us? the only exception i know of is MCE?

perhaps you should start with a clean source and add sp3 again from scratch...

3,773

(2 replies, posted in Software)

not that i know of just bartpe.

although base will add mass storage to your windows source. so in that respect yes we do add mass storage to winPE

um 888111 is included with SP3 you shouldnt have to do anything with it???

3,775

(5 replies, posted in Software)

wow that is quite a contribution!

thanks a million...

PS i added code tags to your code... wink