i see no references betwee n all this mess .-(

we are turning in the circle ...

already doing a half of the above
I need mass storage, and see no reason THAT will require localised.
Just like chipsets should not be localised.

but also sound control panels can be localised...

since mine only needs the HDaudio by realtek, i'll try with only that subfolder too
( a slimmed sound A, put in third packs)

imho, this kinda narrows it down to the KTD changes done in 09 and 10.

the nested D may very well be at the heart of this.
just saw the popup, with only half and a half.. using the base 610
(I decided to get the ATI out of graphics A)

Graphics A (repacked, put it in third party)
sound A
mass
chips
Lan

another idea  is to use an older base with the newest packs and see if the desktop.ini is still there...

think i would test this at first ...

let you know the result ..

I actually have used Nlite  for removing DotnetFX and then did NOT select the dotnetFX addon in RVM, then did m2/KTD and remember I still had it. (I should take notes in a testing logbook... memory could fool me, but I doubt it.)
But, When I tried that, Base610xxx was still an RC version... so it don't count in the current "what's been tried" list of things.

I think I'll use the folowing approach
select only four packs, do it to it.
if the issue is gone, test the other four.
if it comes back, test two out of these four.
is it gone?
test one out of remaining 2

if that narrows it down to a pack... which is possible? Then start removing folders in the pack and repack it.
same method.
half / half etc...

something requires a localised resource, and having said that, it could be related to settings in winnt.sif?

next week, I'll probably build me the third testrig, and I have opted for an ATI card (just for testing that other line of thoughts, which is that it could be an NVidia thing...
BUT... The NVidia videodriver control panel is properly localised (it offers me Dutch menus)

Whatever the cause (maybe even that nested D in D), I would like to help nail it.

sol.exe to keep the mouse happy

the finisher says that it moves the drivers inside "C:\D to C:\windows\driverpacks\D"

now, in windows command, if that D in driverpacks does not exist because you did not create it, and you do
move /y C:\D C:\windows\driverpacks\D
then you do not have the nested D.

BUT, finisher uses another command module, is it not?
HOW does that do things... I dunno

hi
about that desktop.ini popup

I think we should help in trying to narrow down on what causes it.
so; what did I try so far. (so you don't have to, or can verify..)

NO RVM (clean source CD), all packs, KTD all, m2, does it

a suspicion I had about DotnetFX,
I selected the ATI control panel (does not use it), on clean source, m2, ktd.
and got the popup.

unpacked all drivers
searched for a desktop.ini. (nada, zilch)

searched drive what contains the clean source folders.
none in OSes.

will try to eliminate packs, one by one. (each time, M2, KTD all).
will get on the machine I looked at this morning and look at its finisher log.

I'm always amazed by your neverending energy for tracking down these nasty small but annoying bugs! Just saying thanks

I think we should help in trying to narrow down on what causes it.
so; what did I try so far. (so you don't have to, or can verify..)

NO RVM (clean source CD), all packs, KTD all, m2, does it

a suspicion I had about DotnetFX,
I selected the ATI control panel (does not use it), on clean source, m2, ktd.
and got the popup.

unpacked all drivers
searched for a desktop.ini. (nada, zilch)

searched drive what contains the clean source folders.
none in OSes.

will try to eliminate packs, one by one. (each time, M2, KTD all).
will get on the machine I looked at this morning and look at its finisher log.

Toolman wrote:

Actualy it explaines nothing, because NT-compression is transparant to the 'bug' in the driverpack installation ...

Well, I haven't tested it yet, but I think that command changes the permissions of that directory (and its subdirectories and files), which would cause the copy error. You're the only one with this error, and apart from that: it's useless. It would be useful however to apply that command on the %systemroot%\DriverPacks directory.

ebin25 wrote:

same results with latest release

I'm aware of that.

Persmissions will not change because I turned on compression on that folder.
Compression uses the SYSTEM account, where I checked that persmissions are not changed.
(I am busy with MCSE 2003 and that's why I checked all of this. Windows XP is the exam I may skip, because I have 4 core MCSE 2000 certificates.)

Regards,
The Toolman

did u use nlite ?

i also use methode 2 and KTD base 6.10, nlite 1.2b or 1.2rc

so you see that it is a problem only with DRIVERPACK not with anything else!

got home not too long ago...
before I got to work, I had let the testrig run a KTD install
I just looked at the windows\driverpacks\D\D folder mentioned here.

yep; I got it too, hotfixpacks by RVM/Meulc, then DPsBase 6.10 in method2, KTD all.

hmmm
when you first create a folder %systemroot%\driverpacks\D, and then move /y  %systemdrive%\D %systemroot%\driverpacks\D, you will get a nested D.. or windows\driverpacks\D\D

the desktop.ini thing was there too (which happens here when I do KTD, and not when I don't use KTD)

Actualy it explaines nothing, because NT-compression is transparant to the 'bug' in the driverpack installation ...

Well, I haven't tested it yet, but I think that command changes the permissions of that directory (and its subdirectories and files), which would cause the copy error. You're the only one with this error, and apart from that: it's useless. It would be useful however to apply that command on the %systemroot%\DriverPacks directory.

I'm aware of that.

That explains alot.

Please remove the compact command. It's completely useless: the %systemdrive%\D directory is only used for temporary storage of the DriverPacks. If you don't use KTD, all DriverPacks are simply deleted, if you do use KTD, then you should apply this command on the directory specified in the KTDlocation entry of your DPsFnshr.ini. I will add this functionality in one of the next versions of the DriverPacks Finisher anyway, by the way

That only leaves one of the two issues:

me wrote:

the DevicePath value is not cleaned up if you've used method 2

I've fixed that in the current nightly already!

Actualy it explaines nothing, because NT-compression is transparant to the 'bug' in the driverpack installation ...