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

[compstuff]

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:

 

[compstuff]

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.

[yogurt]

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 February 14, 2013 by dotfusion

[bphlpt]

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 February 14, 2013 by bphlpt

[compstuff]

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 February 14, 2013 by compstuff

[mooms]

If you use SAD2 method, size will be merely the same if you left duplicates, thanks to LZMA compression.

[yogurt]

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 February 14, 2013 by dotfusion

[Mr_Smartepants]

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.

[compstuff]

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.

[bphlpt]

Then scanning the folders for any folder that doesn't contain a .inf and deleting that "empty" folder.

I guess we'll need a specially written batch as the easiest way to do this?

Cheers and Regards

[oguz]

I'm following the subject carefully.

I'm waiting for a 100% solution to do so many dublicate driver problem when integrating Win7 and ALL folders. :g:

[yogurt]

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 February 15, 2013 by dotfusion