Search options (Page 151 of 213)

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

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.

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

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

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

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

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

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

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)

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)

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