Jump to content

[Solved] Alphawaves' Downloader and Last Modified dates


PeterWC

Recommended Posts

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 timestamp
  • A few of the updates in the Hotfix subfolder reflect the download timestamp

Also, 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 date

Accessed: 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)

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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 by PeterWC
Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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 timestamp
  • Most 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 by PeterWC
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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 timestamp
  • Most 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 by PeterWC
Link to comment
Share on other sites

Which updates are those please?

 

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)

Link to comment
Share on other sites

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 by PeterWC
Link to comment
Share on other sites

  • 9 months later...

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...