You are not logged in. Please login or register.
DriverPacks.net Forum » Feedback and Support - DriverPacks Base » [Solved] DP Base 8.05 works / 8.12.x "no files to extract" error
I changed the code in presetup.cmd as you asked and tried it. I still get the same error, "no files to extract"
It is IDE and it hooks to my MB via Ribbon cable.
Last edited by EagleWing (2009-01-11 03:06:15)
it did not report
"\OEM\" folder not found. all drive letters were searched
hmmm
try...
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%i:%TAGFILE%" SET CDDRIVE=%%i:& GOTO DPsFound
start /wait Echo "\OEM\" folder not found. all drive letters were searched.
:DPsFound
start /wait dir %CDDRIVE%\OEM\.and tell me if it lists the contents of the OEM folder on the Disc
Please verify that the ODD is correctly jumpered and cabled...
if it is alone on the IDE channel it should be jumpered as master
and at the end of the cable (not in the middle)
if it is jumpered as 'cable select' move it to the 'master' position.
or try a new cable and then a different ODD ...
try overwiting the un7zip.exe that was installed with the 8.12 with the un7zip.exe that came with base 8.05
(they are not the same) What language are you installing? I assume english but assuming is not good 
No it did not report
"\OEM\" folder not found. all drive letters were searched
No it was not jumpered as master and is at the end of the cable and is alone. Changed jumper to master. Made changes to presetup.cmd. Tested and did not work.
However, after reading your suggestions it prompted me to try a test of my own as follows:
v8.05 Default presetup.cmd
REM +==================================================================+
REM | Finding CD/DVD driveletter. |
REM |--------------------------------------------------------------------------|
SET TAGFILE=\OEM
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%i:%TAGFILE%" SET CDDRIVE=%%i:
V8.12.3 Default presetup.cmd
REM +==================================================================+
REM | Finding CD/DVD driveletter. |
REM |--------------------------------------------------------------------------|
SET TAGFILE=\OEM
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%i:%TAGFILE%" SET CDDRIVE=%%i:& GOTO DPsFound
:DPsFound
The rest of the configuration commands is the same in both presetup.cmd files.
I copied the v8.05 Default presetup.cmd file into my I386 directory and replaced the presetup.cmd created by v8.12.3, burnt DVD tested it and it worked.
Apparently the :& GOTO DPsFound
:DPsFound
isn't needed or is it?
Last edited by EagleWing (2009-01-11 13:12:54)
there was some issues with card readers and there needed to be an exit to the loop.
When a empty card reader is encountered the script will hang...
the change prevents this from happening as long as the ODD is found before the card reader.
besides it makes sense to stop searching when you have found what your looking for
(or, why is it that things are always in the last place you look, well who keeps looking after thay have found what the were searching for )
here is the thread that prompted that change
http://forum.driverpacks.net/viewtopic.php?id=2923
try this please (we are getting close now)
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%i:%TAGFILE%" (SET CDDRIVE=%%i:
GOTO DPsFound)
:DPsFoundThat should do it...
But... I just don't see why this one machine alone would fail on this line when it works fine for all others...
It doesn't really matter i guess
if this fixes it let me know and i will update the code in the next release.
Like I said... "I will also add code to save someone else from your issue, if it is possible."
and it would seem that it is possible...
But I am totally at a loss to understand why this particular machine is the only one affected... hmmm
Just throwing this out there - EagleWing, what is your device boot priority in your BIOS? Do you have it set to boot from USB devices before CD/DVD drives?
I see very few BIOS set to boot from USB first, usually it is "Removable"(IE floppy (if one is installed/enabled in the BIOS)) then ROM drives, then hard drives, then USB devices. Almost no name brand setups come differently than that, and very few DIYers bother setting USB higher. But this has tricked me before - nothing more irritating than not realizing someone has USB boot higher in the BIOS and doing a complete, from scratch Windows install and not catching at the very beginning that their empty card reader took C: drive, so now I have an install on G: or whatever!! 
Been tricked by this quite a few times........
Sounds similar to what OverFlow may be suspecting.....
Ian
His issue has solely to do with his machine not parsing that single multi-statement line correctly
I am guessing it read SET CDDRIVE=%%i:& GOTO DPsFound
and then set CDDRIVE to something like "D:& GOTO DPsFound" instead of setting it to "D:"
By enclosing the two statements in brackets and putting a CRLF instead of using an & sign as a separator I will get the same result, it just takes up an extra line and a few extra bytes in the file for no good reason whatsoever.
alternately i might have tried SET CDDRIVE=%%i:&& GOTO DPsFound
for some reason the line is not being parsed correctly on his platform...
could be the AMD processor, RAM or the ODD (resetting BIOS defaults is a valid suggestion lewxam)
I have seen even stranger things than this caused by a video card with RAM issues.
I don't think it is the HDD BUT...
He did say it works if he uses an IDE drive... That is the best clue we have
I apply scientific parsimony here
If there are a number of explanations for observed phenomena, the simplest explanation is preferred.
Something with the HDD... perhaps a caching issue
if this were an Intel box i would suggest flashing the BIOS (which can update the microcode on the CPU too)
There just is not enough info provided to draw any kind of a valid conclusion,
and i don't expect anything to be voluteered,
It's like pulling teeth to get simple direct questions answered.
the questions he did answer, like the error message, he was not even able to copy into his post correctly.
So we may never know why his PC Fails to process a line that millions of other computers have no issue with...
my guess is he built it himself.
I tried your code:
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%i:%TAGFILE%" (SET CDDRIVE=%%i:
GOTO DPsFound)
:DPsFound
Did not work.... That is it did not work until I disconnected my slave drive. In other words with just one hard drive connected to my PC DP Base v8.12.3 worked. Normally I have a master and a slave drive. They are SATA I and SATA II. SATA II being the master and SATA I being the slave. I did go into my CMOS and reset my CMOS settings to default, then set my boot device priority to ROM, HD, Floppy drive. USB not being used as a boot device. This was done when this problem arose. I hope this info helps.
It does help...
did you try (as i suggested above) putting the SATA 1 and SATA 2 HDD's on two different controllers?
Since the drives do not match in speed this can cause timing issues... and may reduce performance also.
Unneeded suggestions removed....
WAIT!!! I lost my focus in the confusion above... I said this before too...
(wake up Jeff...)
"un7zip is in the same location as the packs... it can find the program but not the packs... hmmm..."
That line CAN NOT BE the problem... if it was then it would not find UN7ZIP (DUH...)
BRB
One other line was changed (to try to improve speed) change this line
Start /wait /realtime /separate "" "%CDDRIVE%\OEM\bin\un7zip.exe %CDDRIVE%\OEM\DP*.7z %SystemDrive%\
to
%CDDRIVE%\OEM\bin\un7zip.exe %CDDRIVE%\OEM\DP*.7z %SystemDrive%\
That has to be it. It is the only other difference between the two versions...
I could revert this line in the code. I have had no feedback that it actually does speed up the extraction.
PS it may be that it only fails on /realtime. Changing /realtime to /high probably will work too... not sure.
Start /wait /high /separate "" "%CDDRIVE%\OEM\bin\un7zip.exe %CDDRIVE%\OEM\DP*.7z %SystemDrive%\
perhaps un7zip is unable to handle the unbridled power of an AMD x64 in real time 
Last edited by OverFlow (2009-01-12 08:37:36)
I tried it again after I made the changed the line
Start /wait /realtime /separate "" "%CDDRIVE%\OEM\bin\un7zip.exe %CDDRIVE%\OEM\DP*.7z %SystemDrive%\
to
%CDDRIVE%\OEM\bin\un7zip.exe %CDDRIVE%\OEM\DP*.7z %SystemDrive%\
Did not work.
I did try another test by changing this line
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%i:%TAGFILE%" SET CDDRIVE=%%i:& GOTO DPsFound
:DPsFound
to
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%i:%TAGFILE%" SET CDDRIVE=%%i:
and this worked. It seems to me no matter how you write this command as long as the
GOTO DPsFound
:DPsFound
is included it either misleads or confuses un7zip or something. As for speed it seems to me that that would come from un7zip as it is updated and improved.
Card reader issues are more commonly reported than this issue...
I must include the exit for the loop to address the more common issue...
therefore the line needs to be written so it will exit when the source is found...
I want to fix both issues... your feedback is the single most important part of me achieving that goal.
Thank you for taking the time to try different things and reporting your results
this takes time and effort on your part, I recognize and appreciate this effort.
I will consider some more options and report back... (i hope you used the "subscribe to this topic" button below )
Do you have a Folder named OEM on any of your HDDs?... 
IE C:\OEM or D:\OEM
I have C:\, D:\, and E:\ drives. I did find it on E:\ drive and I deleted it. And yes I will subscribe to this topic. I do appreciate you taking the time and effort to aid me in solving this issue. I have to admit I was somewhat rude and crude in the beginning when I first posted this topic due to frustration. This has been a learning experience for me and I appreciate that.
I am so glad that we are now helping each other... that is the spirit of what we are about.
did you run a test after you found the stray OEM folder?
Was the E:\OEM\ folder missing the DriverPacks? ... 
(that would definitely cause this issue)
presetup would find the folder on E:\OEM\ before finding the OEM folder on your DVD F:\OEM\
if the E:\OEM\ folder contained no packs then that would generate your "no files to extract" error every time...
That seems like the most reasonable explanation to date...
How about changing the presetup.cmd line from:
SET TAGFILE=\OEM
to: SET TAGFILE=\OEM\bin\un7zip.exe
It's being called 6 lines later anyway.
Besides, \OEM isn't a 'tagfile', it's a 'tagdir'.
LOL... it IS a tag folder... good point
but that does not cure either issue 
As I said I deleted the E:\OEM folder and it did not contain any driverpacks. As you asked did I test it after I deleted that folder and the answer is yes I just did. I'll be damned! It Worked! Do you suppose this mystery has been solved? FYI: The following is the code I used when testing.
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%i:%TAGFILE%" (SET CDDRIVE=%%i:
GOTO DPsFound)
:DPsFound
Yes the empty DriverPacks folder on your HDD was getting found first...
and you were being told there was nothing to extract (because there were no DriverPacks files in that folder)
new base uses the first folder if finds
old base uses the last folder it finds...
Solved! User error...
I just got done testing it again using the DP Base 8.12.3 default presetup.cmd and it worked. All this time it must have been the E:\OEM folder with no driverpacks causing this issue. I believe the problem has been solved. And yes it was an user error. By the way I did build this system myself, an excellent educated guess on your part. Thanks again for your time, effort and for tolerating my frustration.
Thanks for retesting and confirming absolutely that we have found the answer.
We are here to help, and I am elated that we were finally able to do so.
I also took a couple of shots at you in frustration,
perhaps we are somewhat alike in that respect.
that may also be the reason we finally were able to work together to succeed.
Thank you for your time and effort.
By sharing your situation here in the forum you have helped to make DriverPacks better for everyone.
That makes you part of our team!
Welcome to DriverPacks and I hope we see you again!
PS You can look forward to getting credit for code similar to the following showing up soon
SET TAGFILE=\OEM
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO (
IF EXIST "%%i:%TAGFILE%\bin\un7zip.exe" IF EXIST "%%i:%TAGFILE%\DP*.7z" SET CDDRIVE=%%i:&GOTO DPsFound)
Start Echo OK, Who's the joker who hid the DriverPacks? & GOTO OUT
:DPsFoundWhat a long and fought out battle for truth, justice, in the American way!
Hello, Gentlemen
Just to clarify that I am a newbie first off. I googled this error this morning: Method 2, 7zip: No files to extract error
I had the same problem for what seemed like months.
I do have 2 WD Sata HDD's, one partitioned in 3, which is great for testing
My DVD's were switched to IDE a while back (SATA DVD's are a whole 'nuther discussion)
I WILL TRY DELETING THE OEM FOLDERS ON THE OTHER DRIVES....
If you need anything from me, it's difficult but I will get it for you.
My hats off goes to you guys! I can't believe that this is even happening out there!
I have lots of people tell me how wonderful I am with computers, but it doesn't even hold a candle to what you gentlemen have done!
It all started for me just buying corporate XP, and after discovering the damn thing wouldn't boot from, I found nlite, BUT THEN: DRIVERPACKS!!!!
Extra KUDOS on all your efforts. Thanks gentlemen.
WAUSHAKA
Hi, gentlemen!
I think it's good idea to check both for OEM folder and Windows tagfile(win51ip.sp3), but I try to write this correction with no luck.
How should the code look for this check.
Thanks in advance!
Native windows drivers are automatically included in a driver search... you don't have to do anything.
The drivers referenced in win51ip.sp3 ( or where ever else they may be, like in a service pack) are what we refer to as native drivers, those are always copied during windows setup to the local system.
the native drivers are all referenced in / from %systemdrive%\INF\ which is the first place searched.
the OEM folder is searched second...
So you're problem is not what you think it is...
Perhaps you should tell us in detail what you tried to do and how you tried to do it...
Please start your own thread and Please read "Read BEFORE you post" linked to in my signature. By including most or hopefully all that info in your first post will speed up getting you to the correct solution or answer.
Welcome to DriverPacks.net
Hello, OverFlow,
Maybe in the previous post was not exhaustive - beg to be excused. I wrote here, because my question is related to the presence of the OEM folder (usually empty) ?? any partition. Some time ago I had exactly the same problem and I correct the TAGFILE's value in PRESETUP.CMD from OEM to WIN51IP.SP3. But if presetup.cmd checks for both tags will avoid the problem with empty or missing OEM folder. Or should have a tagfile in OEM folder.
I try to make check for both tags with no luck.
Greetings.
I correct the TAGFILE's value in PRESETUP.CMD from OEM to WIN51IP.SP3. But if presetup.cmd checks for both tags will avoid the problem with empty or missing OEM folder.
Then your presetup.cmd file will FAIL on any OS other than XP Pro SP3. That tagfile is too restrictive.
As an example:
WIN51IP.SP3 = XP Pro SP3
WIN51IP = XP Pro
WIN51IC = XP Home
WIN51IS = Win2k3 Standard
WIN51AS = Win2k3 Standard x64
WIN51 = XP & 2003
Even using the most basic tagfile of WIN51 will exclude Win2k which uses CDROM_IP.5 and CDROM_NT.5 tagfiles.
The use of the 'OEM' folder is well documented and that folder is present natively ONLY on original source discs (from HP, Dell or systembuilders, etc). We just take advantage of it.
The OEM folder at the root of ANY %systemdrive% is NOT advised.
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
[ Generated in 0.021 seconds, 10 queries executed ]