PeterWC

Ha ha, on first read I thought you said "I've got to look at a theme park first." Yes maybe a little R&R is called for. No problem Lego... © KEiGHT, looks like your patience is about to pay off!

I just tested version "1.4.38.5 - Apr 3, 2014 22:16 UTC" from your sig and it still behaves like the previous versions in this respect. But if you are teasing me with a subtle announcement regarding a new version then I can wait. EDIT: You just posted v1.4.38.6 - but still not working (for me at least): *AIO|v1.4.38.6|Tuesday 08 April 2014 12:15:19 AM#UpdatesE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2461631-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2487292-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2506014-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2493989-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2506928-v2-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2492386-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2608658-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2660075-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2640148-v2-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2699779-v2-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2709981-v2-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2685811-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2685813-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2719857-x64.msu#OptionsCompatibility CheckCreate BackupsEnable CMDFailed Updates to Silent InstallersIntegrate 'HDC' Drivers (boot.wim)Integrate 'SCSIADAPTER' Drivers (boot.wim)Integrate 'SYSTEM' Drivers (boot.wim)Move Known Problem Updates to Silent InstallersPrepare DriversPrompt AddonsPrompt DriversPrompt GadgetsPrompt SilentPrompt ThemesPrompt UpdatesPrompt WallpapersRebuild ImageRemove Invalid DriversRetry UpdatesShow Duplicates

Now [solved]? Then where is my coffee spigot? :fun:

Yup I think I saw your post about that. Will let Lego prioritize the bug fixes, since he's doing all the work. Cheers! :beerchug:

I've got plenty of patience, thanks.

Yes I understand the concept of prerequisites, thanks. That's why it's more efficient to put things in release order, don't you think? In any case, there is a sortable list view in the window and by all expectations the sort order should be observed, even if I chose something as silly as integrating by MD5 checksum order. And the "Save Preset" portion of the code does observe the selected column sort. Just trying to get the actual GUI to follow suit...

"reserved" :dizzy:

© KEiGHT, your suggestion is certainly a good workaround for the bug in WinToolkit Installer. There is already an open post on that topic in which you've contributed your suggestion (thanks for that). I'm including a link here for the benefit of anyone else reading this thread: http://www.wincert.net/forum/topic/12152-runonce-changes-install-order/ In the case of this bug with AIO Integrator, the workaround is to Save Preset then Load Preset and use that for the Integration. I'm hoping we can get this bug squashed since it seems that all the required parts are already present in the WTK code. (Peter)

That's not the All-In-One Integrator but a totally different topic. And yes, while it's possible to add a prefix to every KBnnnnnnn.msu file to get the updates to sort in a particular order within AIO Integrator, that really would not be practical (e.g. when using Alphawaves' Downloader, which would no longer recognize the updates). The goal here is to get AIO to integrate in the column sort order. In my case I want to sort and integrate by the "Date" column, which is the file Creation date, which when obtained via Alphawaves' Downloader corresponds to the Release date. Here is what happens when I sort by Date and then press Start. Note that the updates are still being integrated by filename order (which is the order in which they were selected in the file picker dialog). But here is the contents of the Preset file that was saved when prompted immediately after clicking the Start button, just before the actual integration began. Note that the correct order by Date is preserved there (these are the first 14 updates by Created/Released date from WinToolkit\Updates\Windows7-x64\General): *AIO|v1.4.38.4|Thursday 03 April 2014 7:21:16 AM#UpdatesE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2461631-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2487292-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2506014-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2493989-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2506928-v2-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2492386-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2608658-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2660075-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2640148-v2-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2699779-v2-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2709981-v2-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2685811-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2685813-x64.msuE:\Slipstream\WinToolkit\Updates\Windows7-x64\General\Windows6.1-KB2719857-x64.msuClear now?

Bumping this topic as I'm fairly certain it can be quickly fixed (not fixed yet as of test build 1.4.38.4.)... To reiterate: AIO Integrator is aware of column sort order and is correctly saving it to a Preset when prompted; but it is not using that order for the actual integration. "Should be" easy enough for AIO Integrator to read whatever data structure it's using to capture sort order at that moment and apply to the actual integration (instead of having to go Load the just-saved Preset to accomplish that task). :g:

This is indeed fixed in test build 1.4.38.4. Thanks again Lego!

I was seeing this issue with v1.4.38.2, but I'm not seeing anything newer in your sig yet... Regarding sort order not being observed, this doesn't seem to be an issue with customs sorts using the Move buttons. (BTW this is another good reason to disallow column sorting after integration starts: If you sort via the Move buttons then click a column header, you can't restore the button-driven sort order, and from that point integration would probably appear to be jumping all over the list.) I'm a bit confused as to why you can't capture column sort in the list. As i mentioned above, a saved Preset does capture any non-default column sort. Can't you simply use the same structure that is used to create the preset to actually run the integration?

Using the latest test build 1.4.38.2: In the Drivers tab of AIO Integrator, the status pane at the bottom defaults to "Checking for invalid drivers..." Expect to see some explanatory text here instead (like we do at the bottom of the other tabs), e.g. "Add out-of-box drivers to support your devices!" :cap:

Would appreciate being able to integrate DriverPack (http://driverpacks.net/) archives directly in the Drivers tab of AIO integrator, without having to expand them beforehand. These are 7-zip archives, not sure if you have a suitable decomposer already built-in to Win Toolkit? Would also be helpfult to directly integrate regular .zip archives from other sources. Maybe even RAR? Thanks... EDIT: Want to make it clear that I'm not looking for a way to blindly fold in an entire DriverPack (I did search for and read all related posts here on that subject). Just hoping to have AIO Integrator "peek" into 7-zip and .zip (and possibly RAR) archives directly, then display the found .inf files in the Drivers window, to allow manual selection or removal of individual drivers from the list to be integrated.

Looks good, thanks Lego. :dancing:

This is happening to me in the Updates + Languages tab of All-In-One Integrator. Other tabs could be affected but I have not checked them... Steps to reproduce: Add a randomly selected group of updates, e.g. the first 15 files listed in \Updates\Windows7-x64\GeneralSort the Updates + Languages window by something that does not key on filename, e.g. Size, MD5, or the new Date columnAIO Integrator still integrates in "pick" order, i.e. the order in which the files were selected in the file chooserThe good news is that Presets are correctly saved in the order displayed in the window. So a workaround is to cancel the integration right after saving the preset, then start over by selecting the saved preset. A related bug/issue: All-In-One Integrator allows me to change the sort order after integration has begun. One could infer that inegration would then follow the new sort order... The file selection buttons in left-hand pane of the window are no longer available after integration has begun. Should column sort be disabled as well? EDIT: Behavior observed in both latest released version 1.4.37.20 and latest test build 1.4.38.2.

What's New in Version v1.4.37.20 (See full changelog) [...]*1.4.37.6^Alphawaves' Downloader now sets Last Modified as release dateShould say "sets Created date as release date" (my bad for the confusing the issue with my original take on this...)

Follow-on to my bug report here: http://www.wincert.net/forum/topic/12117-solved-alphawaves-downloader-and-last-modified-dates/ With the latest test builds of Win Toolkit, Alphawaves' Downloader is now consistently assiging the Release date to the Created date for each downloaded file... Since this data is available from the update files themselves, it "should be" trivial to add a sortable column to the "Updates + Languages" tab of AIO Integrator, which reads the Created timestamp off each added file. The label on this column could be as ambiguous as "Date (YYYY/MM/DD)" (just as it shows in the Downloader). That way you are not committing to any of this data actually being accurate or relevant (GIGO after all ). And the Created date for Language packs may actually have nothing to do with any particular release date; yet those dates would probably also appear here. So a simple "Date" label should be useful enough without being misleading in any way (though it might make things clearer here to use "Created date" -- your call on that). I feel this would be a step in the right direction towards being able to install updates in some rough order of actual release date. As I mentioned in a post several months ago (http://www.wincert.net/forum/topic/11612-update/page-2#entry103041), "updates are not necessarily released in numerical order, and re-releases break such order anyway, and there are actually several different numerical sequences being used by MS, it makes more sense (to me at least) to sort updates by [...] date (which is what I do when I add them to the Updates + Languages tab in Win Toolkit)" Thanks in advance for your consideration. (Peter)

I see that references to Alphawaves have been fixed in v1.4.37.17. Will make a new post in the Win Toolkit Requests subforum to have "Date (YYYY/MM/DD)" added to AIO Integrator. Thanks again Lego.

Donated. :beerchug:

Sorry for the delay, and also thanks to Cartman. Yes this looks good to me as well. Created dates reflect Release dates, Last Modified/Accessed reflects download dates. Can we please get this issue fixed for proper attribution to Alphawaves: P.S. Alphawaves' name should also be corrected in the Credits sections on the Updates tab of WTK. And finally... Can you possibly add a sortable "Date (YYYY/MM/DD)" column to the "Updates + Languages" tab of AIO Integrator? I know this is more of a feature request than a bug report, but it's one reason behind me pushing so hard to get this feature of the Downloader straightened out (or figured out, as the case may be). Thanks Lego!

These are the General updates that still show the release timestamp for Date Modified & Accessed: Windows6.1-KB2461631-x64.msu Windows6.1-KB2493989-x64.msu Windows6.1-KB2846960-x64.msu Windows6.1-KB2928562-x64.msu Windows6.1-KB2908783-x64.msu These are the only Hotfix updates that actually show the download timestamp for Date Modified & Accessed: Windows6.1-KB2878378-v2-x64.msu Windows6.1-KB2847077-x64.msu Windows6.1-KB2810177-x64.msu Windows6.1-KB2797789-x64.msu Windows6.1-KB2780124-x64.msu Windows6.1-KB2755625-x64.msu Windows6.1-KB2732072-v3-x64.msu Windows6.1-KB2584475-x64.msu Windows6.1-KB2612905-v4-x64.msu Windows6.1-KB2465285-x64.msu (Security updates all show the download timestamp for Date Modified & Accessed)

Using 1.4.37.9, I also generally see the same results: CreationTime: Release Date LastAccess/Write: Download date Creation date appears to consistently use the Release date. :grin: Unfortunately now the Last Modified & Last Accessed timestamps are following the original inconsistent pattern: All of the updates in the Security subfolder reflect the download timestampMost of the updates in the General subfolder reflect the download timestamp (five updates show release timestamps)Only a few of the updates in the Hotfix subfolder reflect the download timestamp (all but ten updates show release timestamps)??? Will check again later, it's late here where I live.

For reference, I just ran Alphawaves' own Windows Hotfix Downloader and downloaded all of the available General updates via that tool. With WHD, the Created date on the downloaded files is the same as the Release date displayed in the tool, and Last Modified and Accessed dates reflect Download date & time. Alphawaves doesn't bother listing Download dates in the tool, and I'm not sure what the benefit is with showing that date in Win Toolkit. My previous request to have Last Modified reflect release date (http://www.wincert.net/forum/topic/11612-update/?p=103041) was based on a simple desire to have some method to sort by release date. It would be easy enough to enable the Created date column in Explorer and sort by that when adding hotfixes to Win Toolkit. For consistency's sake, it might be best to follow Alphawaves' lead here and use the same timestamps in the same places. In any case, with the latest Win Toolkit release, some files are still not getting stamped correctly (see my previous post).

Thanks again, we're almost there... I just deleted my previous "Updates" folder then used Win Toolkit v1.4.37.6 to download all 433 "New Updates [Recommended]" again. Last Modified dates are all something other than current, so I think we've got that part correct now (will cross-check each one with the published release dates later today). With regards to Created and Accessed dates, for every file they are both the same; but there are some cases where the file is using the release date instead of the download timestamp for these two dates: All of the updates in the Security subfolder reflect the download timestampMost of the updates in the General subfolder reflect the download timestamp (five updates still show source timestamps)Only a few of the updates in the Hotfix subfolder reflect the download timestamp (only ten updates show download timestamps)This is the same pattern I was seeing with v1.4.36.2 (see my OP above), but now we are seeing it with regards to the download timestamp (instead of the release timestamp). So this is definitely a bug and not due to any preference of one timestamp over the other. BTW, Win Toolkit threw an error while processing \Updates\Windows7-x64\Hotfix\Windows6.1-KB2614892-x64.exe. It popped up a message or two in the system tray and when i clicked on one of those messages it tried to upload the log to an Adf.ly page. But the URL was malformed, something like http://www.adf.ly/E:\Slipstream\WinToolkit\Logs\logname.log i.e. it included the literal local path to my Win Toolkit directory and so Adf.ly complained about an error. I've zipped up the log and attached it to this post. I confess that I negelected to disable Microsoft Security Essentials so maybe I was pushing this just a little too hard. :shifty: Need to get some sleep now, will take another look at any new builds when I wake up. EDIT: Just tried v1.4.37.7 and I'm seeing the exact same results. I've added notes in bold to the bullets in this post for more details. error.zip