Jump to content

Drivers added with WinToolKit marked in blue and other another question?


oguz

Recommended Posts

I know exactly what you mean and I have wondered the same thing but I have been successful it deleting the partial aspects of folders and creating fully functional images BUT I really think we are all on an excellent track to make a huge impact in driver integration so I am revisiting my entire method and will experiment with everyone's ideas and input

I think it is dangerous to delete duplicate files, because sometimes they are (or seems at least) necessary.

I have tested DFF in DP_LAN_wnt6-x64_1208 after deleting others OS folders (left Win7 and All): it found some duplicated files in some folders, but the others files in the same folders are not duplicates ! (they are indeed same files but belongs to another "sets" of drivers)

So if we delete one each of the files, we are left with "incompletes" folders and I think the drivers can't be installed.

 

I don't know if it's clear, rather see the image to understand what I'm saying:

 

130213063853547857.png

Link to comment
Share on other sites

I'm sorry I over looked that aspect in your images and post... I have a lot of work stuff going on and I am trying to figure out how to explain my Step 2 in my other post lol

 

I actually do delete the non relevant OS folders and I only leave the ALL and the WIN7 ...as I get a little more off my plate I will provide my examples as well for everyone's review.

 

On a side note I hope this whole issue/topic renews support for the DriverPack forum and creation of packs (meaning more people helping to make the packs). I have definitely not been as active as I should...

I just want to bring something to your attention that I've only just realized before you try my method. Mr_Smartepants and mooms have pointed out to me that It may be wise to remove non-releavant OS folders first, prior to scanning for duplicates. The reasons can be clearly seen in posts #20, #22, and #23.

Link to comment
Share on other sites

What I have learned thus far is that folders in which Duplicate driver files are found are safe to purge from a DriverPack. These 'now' incomplete driver folders will be satisfied by the surviving driver file / folder. Make sense since the source source files of the duplicate are identical to the source files of surviving driver / folder and  their should be no adverse effects with the installation of the custom 7 build.

Edited by dotfusion
Link to comment
Share on other sites

I guess that assumes that the incomplete driver folders can automatically find the surviving file/folder somehow?  Ideally, I would think it would be better if the duplicate files could be replaced by a hard link to the surviving files.  They might still show up as duplicates, but they wouldn't take up any real space on your disk.  I know there used to be a "duplicate file finder" type app that had that as an option of what to do with duplicates, but I can't remember which app that was and so can't put my finger on it.  If I ever find it again I'll post about it.

 

Possible options I found are:

 
Duplicate Commander - Freeware - Info on main page, also available as portable version
 
NoClone - Shareware -US$26.8 - Info
 
TreeSize Pro - Commercial software with Trialware - US$52.95 - Info

 

Cheers and Regards

Edited by bphlpt
Link to comment
Share on other sites

I never thought about the hard link concept before... since I also leave "partial" folders in place after I remove the duplicate drivers this seems like a great idea even though I don't actually "fully" understand the way DISM works driver integration. This leads me to ask a larger question; if we incorporate a SAD2 method into our driver integration, other than size and speed, what difference does having duplicate drivers actually make? DISM addresses this doesn't? It's doesn't cause problems does it? If it doesn't actually cause problems I am wondering if I am just over complicating things for myself.

 

With that said I am going to try Duplicate Commander this weekend 

 

I guess that assumes that the incomplete driver folders can automatically find the surviving file/folder somehow?  Ideally, I would think it would be better if the duplicate files could be replaced by a hard link to the surviving files.  They might still show up as duplicates, but they wouldn't take up any real space on your disk.  I know there used to be a "duplicate file finder" type app that had that as an option of what to do with duplicates, but I can't remember which app that was and so can't put my finger on it.  If I ever find it again I'll post about it.

 

Possible options I found are:

 
Duplicate Commander - Freeware - Info on main page, also available as portable version
 
NoClone - Shareware -US$26.8 - Info
 
TreeSize Pro - Commercial software with Trialware - US$52.95 - Info

 

Cheers and Regards

Edited by compstuff
Link to comment
Share on other sites

I guess that assumes that the incomplete driver folders can automatically find the surviving file/folder somehow?

 

Not really because because the surviving driver.inf [install_section] is identical to that of the deleted driver.inf (remember they are duplicates) The surviving driver.inf that remains resides in it's OS folder along with all the source files required for a successful installation. No?

Edited by dotfusion
Link to comment
Share on other sites

Hard links (or symbolic links) don't work.  I already tried that for a separate project.  DISM will map the absolute path, not the path of the symbolic link.

 

For deleting duplicate files, you'd be better served scanning/deleting duplicate .inf files only.  Then scanning the folders for any folder that doesn't contain a .inf and deleting that "empty" folder.

Some .inf files have dependent files mapped in such a way that even deleting a file that doesn't apply to the OS at all will still break the driver package as a whole.

 

A good example of this is the driver in DP_Audio_wnt6-x86_1207\x86\S\RME\1\.

There is only one .inf.  Inside it references hdsp_64.sys as mandatory, even on a 32-bit system where it would be ignored.  But if you remove that 64-bit file, you break the whole driver and it will refuse to install.

Link to comment
Share on other sites

Thanks for the info you saved me some testing time

Hard links (or symbolic links) don't work.  I already tried that for a separate project.  DISM will map the absolute path, not the path of the symbolic link.

 

For deleting duplicate files, you'd be better served scanning/deleting duplicate .inf files only.  Then scanning the folders for any folder that doesn't contain a .inf and deleting that "empty" folder.

Some .inf files have dependent files mapped in such a way that even deleting a file that doesn't apply to the OS at all will still break the driver package as a whole.

 

A good example of this is the driver in DP_Audio_wnt6-x86_1207\x86\S\RME\1\.

There is only one .inf.  Inside it references hdsp_64.sys as mandatory, even on a 32-bit system where it would be ignored.  But if you remove that 64-bit file, you break the whole driver and it will refuse to install.

Link to comment
Share on other sites

I'm going to try Mr_Smartepants suggestion and test on my next. build. All this new information on driver integration has brought me to rethinking my process for cleaning up DriverPacks. Thanks everyone for sharing your insight.

 

For deleting duplicate files, you'd be better served scanning/deleting duplicate .inf files only. Then scanning the folders for any folder that doesn't contain a .inf and deleting that "empty" folder.

Edited by dotfusion
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...