0000434: DevPath not able to scan all paths

(0000773)
OverFlow (administrator)
2008-05-21 23:31

i have been looking for other issues...
I was haveing trouble with the code for bartpe too...
i think the easy fix is to create a subfolder to move them to.
i wrote a routine for the bartpe platform to detect the zero subfolders exist path (like in cpu)

I am certain this is not checked for on the disk platform but i could use the same routine for both modules

Ultimately i belive this to be an error in the packs layout.
although it has been this way since version 6.19 at least, and never reported.

i suggest we take a two fold approach to solve

1 make this pack compliant with the other packs.
  a) create at least one subfolder
  b) a single alphanumeric character name ( IE D\CPU\A\ )

2 harden the base code against such user error;
  a) add folder check code to disk platform module

(0000777)
OverFlow (administrator)
2008-06-02 20:31

the layout of cpu folder was altered in the nightlies for testing
the pack is now compliant with the other packs

(0000780)
OverFlow (administrator)
2008-06-16 21:52

did the test version solve this issue?

(0000786)
DeTard (reporter)
2008-06-17 11:17

Well it works so long as you make the pathing include the D directory. So if I have C:\Windows\D\CPU, yeah it works. If I just tell it to look in C:\Windows\CPU, no it does not. Apparently it's hardcoded to look in a path with D?

(0000787)
OverFlow (administrator)
2008-06-17 12:26

i havent used ktd in a long time

i belive it is supposed to look in c:\windows\driverpacks\

by default

(0000788)
DeTard (reporter)
2008-06-17 12:29

This wasn't KTD. I manually had placed the drivers for CPU there at the time I was working with the network driver repository.

(0000789)
OverFlow (administrator)
2008-06-17 12:32

I will have to look at that part of the code more closely ;)

(0000790)
DeTard (reporter)
2008-06-17 12:52

Well to be totally honest, to me this isn't very important any longer, but possibly someone else will have a reason to place drivers in custom paths. As suggested by someone on the forum, I started using Sysprep Driver Scanner, and I'm fairly confident in it's useage now that I can see in verbose detail what directories are being added to the registry prior to commiting the change.

Issue History
Date Modified	Username	Field	Change
2008-05-15 12:08	DeTard	New Issue
2008-05-15 12:08	DeTard	Status	new => assigned
2008-05-15 12:08	DeTard	Assigned To	=> BashratTheSneaky
2008-05-15 12:08	DeTard	Destination OS Platform	=> wnt5_x86-32 (Windows XP)
2008-05-15 12:08	DeTard	Installation Platform	=> not applicable
2008-05-15 12:08	DeTard	DriverPacks	=> not applicable
2008-05-15 12:08	DeTard	DriverPacks Method	=> 2
2008-05-15 12:08	DeTard	DriverPacks Finisher Method	=> not applicable
2008-05-21 23:13	OverFlow	Assigned To	BashratTheSneaky => OverFlow
2008-05-21 23:31	OverFlow	Installation Platform	not applicable => other (not natively supported)
2008-05-21 23:31	OverFlow	DriverPacks	not applicable => CPU
2008-05-21 23:31	OverFlow	DriverPacks Finisher Method	not applicable => custom
2008-05-21 23:31	OverFlow	Note Added: 0000773
2008-05-21 23:31	OverFlow	Status	assigned => acknowledged
2008-06-02 20:31	OverFlow	Note Added: 0000777
2008-06-02 20:33	OverFlow	Status	acknowledged => confirmed
2008-06-16 21:52	OverFlow	Note Added: 0000780
2008-06-16 21:52	OverFlow	Status	confirmed => feedback
2008-06-17 11:17	DeTard	Note Added: 0000786
2008-06-17 12:26	OverFlow	Note Added: 0000787
2008-06-17 12:29	DeTard	Note Added: 0000788
2008-06-17 12:32	OverFlow	Note Added: 0000789
2008-06-17 12:52	DeTard	Note Added: 0000790
2008-06-17 17:08	OverFlow	Status	feedback => closed
2008-06-17 17:08	OverFlow	Resolution	open => fixed
2008-07-16 21:33	OverFlow	Status	closed => resolved

Notes
(0000773) OverFlow (administrator) 2008-05-21 23:31	i have been looking for other issues... I was haveing trouble with the code for bartpe too... i think the easy fix is to create a subfolder to move them to. i wrote a routine for the bartpe platform to detect the zero subfolders exist path (like in cpu) I am certain this is not checked for on the disk platform but i could use the same routine for both modules Ultimately i belive this to be an error in the packs layout. although it has been this way since version 6.19 at least, and never reported. i suggest we take a two fold approach to solve 1 make this pack compliant with the other packs. a) create at least one subfolder b) a single alphanumeric character name ( IE D\CPU\A\ ) 2 harden the base code against such user error; a) add folder check code to disk platform module

(0000777) OverFlow (administrator) 2008-06-02 20:31	the layout of cpu folder was altered in the nightlies for testing the pack is now compliant with the other packs

(0000780) OverFlow (administrator) 2008-06-16 21:52	did the test version solve this issue?

(0000786) DeTard (reporter) 2008-06-17 11:17	Well it works so long as you make the pathing include the D directory. So if I have C:\Windows\D\CPU, yeah it works. If I just tell it to look in C:\Windows\CPU, no it does not. Apparently it's hardcoded to look in a path with D?

(0000787) OverFlow (administrator) 2008-06-17 12:26	i havent used ktd in a long time i belive it is supposed to look in c:\windows\driverpacks\ by default

(0000788) DeTard (reporter) 2008-06-17 12:29	This wasn't KTD. I manually had placed the drivers for CPU there at the time I was working with the network driver repository.

(0000789) OverFlow (administrator) 2008-06-17 12:32	I will have to look at that part of the code more closely ;)

(0000790) DeTard (reporter) 2008-06-17 12:52	Well to be totally honest, to me this isn't very important any longer, but possibly someone else will have a reason to place drivers in custom paths. As suggested by someone on the forum, I started using Sysprep Driver Scanner, and I'm fairly confident in it's useage now that I can see in verbose detail what directories are being added to the registry prior to commiting the change.

Relationships