PeterWC Posted March 23, 2014 Posted March 23, 2014 I see that the "Alphawave's Downloader" feature in Win Toolkit is (trying to) use the update's release date for the downloaded file's timestamp. Thanks very much for that! I just used Win Toolkit v1.4.36.2 to download all 433 "New Updates [Recommended]". Checking the results for Last Modified date in Windows Explorer:All of the updates in the Security subfolder reflect the download timestamp (not the release date)Most of the updates in the General subfolder reflect the download timestampA few of the updates in the Hotfix subfolder reflect the download timestampAlso, in the "Downloaded" tab of the Downloader, for those files that (incorrectly) show the download timestamp in Explorer, the "Downloaded" column accurately reflects the download date. But for files that correctly show the release date in Explorer, the "Downloaded" column also shows the release date, which is a bit misleading. Perhaps this column can instead show the Created date? (but still keep the "Downloaded" label...) Looking deeper, I see that some (but not all) of the files that do show release date in the Last Modified timestamp have other timestamps that don't look right. For instance, Windows6.1-KB2800095-x64.msu (in the Hotfix subfolder): Created: Friday, February 28, 2014, 1:36:10 AM <--- ???Modified: Wednesday, January 29, 2014, 12:11:13 AM <--- actual release dateAccessed: Friday, February 28, 2014, 1:36:10 AM <--- ??? Are these Created and Accessed timestamps actually taken from the source file? If so, then my previous suggestion to use the Created date may not be of any use. Perhaps you can set just the Modified date, and let the filesystem handle the Created and Accessed date? Minor nit: This feature uses functionality provided by the user "Alphawaves" @ MDL. So it should be labeled "Alphawaves' Downloader" (note the relocated apostrophe). Thanks! (Peter) Quote
PeterWC Posted March 23, 2014 Author Posted March 23, 2014 P.S. RicaNeaga Updates are apparently no longer being maintained? At least not at the MEGA page that the button in Win Toolkit points to. There's nothing newer than 2014-01-22 at that page. Note name for first file in list there: "NOT GOING TO UPDATE THESE ARCHIVES ANYMORE - PLEASE USE WHD APP - LINK FOR IT INSIDE.txt" File contains an old link to Alphawaves' Windows Hotfix Downloader @ MDL. (didn't bother putting this in a separate post as I'm not interested in the Bug Bounty, thanks) Quote
Legolash2o Posted March 23, 2014 Posted March 23, 2014 I've removed RicaNeaga link. I've also made it so any NEW downloaded files LastAccess, LastWrite, Creation date are all set the release date. PeterWC 1 Quote
PeterWC Posted March 23, 2014 Author Posted March 23, 2014 (edited) Wow! Thanks for the speedy update... But i'm a bit confused about making all three timestamps the same... this will make the "Downloaded (YYYY/MM/DD)" column always reflect the release date, not the download date, no matter which timestamp that column reads. Seems to me that you need to let Created timestamp reflect actual downloaded date/time, and read that for the "Downloaded (YYYY/MM/DD)" column. Otherwise there will be no use for that column.... Unless it's keeping track of download timestamps somewhere else? Edited March 23, 2014 by PeterWC Quote
Legolash2o Posted March 23, 2014 Posted March 23, 2014 OK i'll set creation date as release date and last write/access to current date. EDIT: Done. Quote
PeterWC Posted March 24, 2014 Author Posted March 24, 2014 Actually, what we need is Modified date as release date, so that we can sort by that column in Explorer when selecting updates to Add to Win Toolkit. Created and Accessed dates can just default to current date. And Win Toolkit should use Created date for the "Downloaded (YYYY/MM/DD)" column. (Using Last Modified there will be redundant since that date will already be reflected in the "Date (YYYY/MM/DD)" column.) Using Modified date as release date, and Created and Accessed dates as current date, mimics how Explorer handles file copies across local volumes. Modified date is always preserved (unless the file is actually modified), Created and Accessed dates reflect when the file was copied. (Accessed can subsequently change if the default NTFS behavior is in force.) This will go a long way towards getting updates applied in roughly the original release order, without having to maintain internal lists within Win Toolkit. In fact, this feature in Windows Update Downloader ("WUD", not WHD) is the only reason I'm still hanging onto that legacy app. I'm anxious to get on with using your port of WHD. You've put a lot of work into it and it fits nicely into Win Toolkit. Thanks for your patience, and I do appreciate you hearing me out on this. (Peter) Quote
Legolash2o Posted March 24, 2014 Posted March 24, 2014 OK, consider it done EDIT 1: I'm just making it so currently download files show the correct date too.EDIT 2: Done Quote
PeterWC Posted March 24, 2014 Author Posted March 24, 2014 (edited) 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 Edited March 24, 2014 by PeterWC Quote
PeterWC Posted March 24, 2014 Author Posted March 24, 2014 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). Quote
Legolash2o Posted March 25, 2014 Posted March 25, 2014 Ok I've now set: CreationTime: Release DateLastAccess/Write: Download date. Hopefully fixed the bug where they where not being set correctly. I'm guessing those updates where old and no longer in the list. Quote
PeterWC Posted March 25, 2014 Author Posted March 25, 2014 (edited) Using 1.4.37.9, I also generally see the same results: CreationTime: Release DateLastAccess/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. Edited March 25, 2014 by PeterWC Quote
abbodi1406 Posted March 25, 2014 Posted March 25, 2014 Most of the hotfixes are downloaded in sfx zip files and then extracted (this include 5 of the general updates) maybe this is the cause of the inconsistent dating pattern, the timestamp is set for the zip file not the extracted msu file? PeterWC 1 Quote
Legolash2o Posted March 25, 2014 Posted March 25, 2014 Good point! I will check once I get home. Thank you. Quote
PeterWC Posted March 25, 2014 Author Posted March 25, 2014 Which updates are those please? These are the General updates that still show the release timestamp for Date Modified & Accessed: Windows6.1-KB2461631-x64.msuWindows6.1-KB2493989-x64.msuWindows6.1-KB2846960-x64.msuWindows6.1-KB2928562-x64.msuWindows6.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.msuWindows6.1-KB2847077-x64.msuWindows6.1-KB2810177-x64.msuWindows6.1-KB2797789-x64.msuWindows6.1-KB2780124-x64.msuWindows6.1-KB2755625-x64.msuWindows6.1-KB2732072-v3-x64.msuWindows6.1-KB2584475-x64.msuWindows6.1-KB2612905-v4-x64.msuWindows6.1-KB2465285-x64.msu (Security updates all show the download timestamp for Date Modified & Accessed) Quote
PeterWC Posted March 26, 2014 Author Posted March 26, 2014 (edited) Try the latest build please 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:Minor nit: This feature uses functionality provided by the user "Alphawaves" @ MDL. So it should be labeled "Alphawaves' Downloader" (note the relocated apostrophe).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! Edited March 26, 2014 by PeterWC Quote
PeterWC Posted March 27, 2014 Author Posted March 27, 2014 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. Quote
PeterWC Posted March 28, 2014 Author Posted March 28, 2014 (edited) 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...) Edited April 3, 2014 by PeterWC Quote
Ricky Araneta Posted January 10, 2015 Posted January 10, 2015 hi.. am no using the latest version 1.5+ i have a question about adding iso into my windows 8.1.. after adding that updates and make an iso file the will be also installed according to the release date? thanks Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.