[Inki]

After patch Tuesday this June, I used the June 6 beta version of HFSLIP to make a new installation disk with W2k + USP5.1 + WMP9 + a whole lot of HF's.

I found two strange things:

1. Modification time stamps on updated files in the system after installation appear to have come from the time HFSLIP packed them into ??_-cabinets, rather than the true modification date of the file in question. The time stamp of the actual files inside the cabinets in sourcess and on the installation disk appears to be correct, however. This seems to affect all updates, based on examining some random samples.

2. Files from the latest IE6SP1 cumulative update were installed, but the update was not recognized by MBSA or WU. Installing it then via WU was successful in the sense that the update was then properly recognized. However, the files with incorrect time stamps remain. No problems were immediately apparent with any other updates.

I have never seen this behaviour before and have no idea what is going on with the time stamps. I am half expecting that I have done something silly, and would appreciate any suggestions as to what that could be.

Attached File(s)

•  HFSLIP.zip (1.58K)
  Number of downloads: 3

[tommyp]

Timestamps of the new files will be the date that hfslip is run. I took a look at your hotfixes, it seems that you are mixing and matching various things and it's not being done correctly. May I suggest that you visit the hotfix stickied post in this forum. Oh, IE6 won't slipstream via hfslip because you do not have the ie6 cabs present in hfcabs. You should doublecheck all that you have populated and fix the errors.

[Inki]

Thank you for your comments. I greatly appreciate your rapid feed back.

I am still baffled by the time stamps, because I have usually checked my installation by doing spot checks of both version numbers and time stamps against those given for the updates, if I remember correctly. I may be gravely mistaken, but either HFSLIP or Windows changing the modification time stamps during installation seems weird to me. I'll take your word for it, though.

IE6SP1 is very much present even without the cabs, because it comes with USP5.1, and I saw it in action when using WU.

I will certainly continue to check my HF population, which may be a bit superfluous, but has never really created major problems before. If you are referring to updates being present for both MP6 and MP9, that is intentional and experimental, (and the experiment also covers logagent.ex_ in replacements).

P.S.
And my apologies for the messy HF population. Deep inside I knew that I really should have a clean presentable version in addition to the collection of obscurities that I have been working with. Still, I decided to post it as it is, just in case it might reveal something else useful.

P.P.S.
I thought I might as well air some thoughts on MP6 vs. MP9: As far as I can tell, W2k comes natively with MP6, and I am not aware of any method to totally eradicate it. Some MP6 files remain even if one installs MP9, and MP6 actually remains operational. Therefore, my thinking is that it makes sense to keep those MP6 files also updated as far as possible, and I think WU also would suggest so. As far as I can tell, MP6 and MP9 hotfixes mostly are not even overlapping or conflicting, so it seems reasonable to apply them both in an attempt to simulate a situation where one would have MP9 installed on top of a fully patched MP6. In one case, however, the udates in MS08-076 for MP6 and MP9 do conflict. Both contain the file logagent.exe so that the MP6 version has a lower version number but a later date, causing it to be selected by HFSLIP, which is why I have the MP9 version of the file in the replacements folder. An alternative experiment would be to only include the MP9 hotfix from MS08-076, and to replace the MP6 hotfix with just the file streamdll.dll, the only one that would not be overwritten by MP9. I am sure that this all appears very nutty, but it is just some light-hearted experimentation, not to be taken too seriously.

P.P.P.S.
This might not be relevant at all, but I thought I'd just bring up two previous cases, where I have had issues with USP5.1, that were resolved, just in case it might be helpful:
- Possibly two file copying issues with W2k SP4 patches, concerning MS07-057 and MS06-057
- Possible peculiarity relating to driver integration, using HFSLIP 1.7.3 with W2kSP4 and USP5.1

This post has been edited by Inki: 15 June 2009 - 03:42 AM

[tommyp]

I don't see the usp5 in your HF list. The filename should be something along the lines of w2ksp5. Are you installing usp5 after the fact? Or was it pre-slipstreamed? If it's the latter, you should really use a virgin source and let hfslip slipstream it for you instead.

[Inki]

Yes, USP 5.1 is pre-slipstreamed, HFSLIP.LOG: "OS in SOURCESS - Windows 2000 Professional SP4 (USP5.x) English"

That is how it has worked for me over several years, and it slightly reduces processing done by HFSLIP. Now, I have not run HFSLIP for several months prior to this June, but I did run 1.7.9_beta_d in January, though, without incident.

Of course, if a pre-slipstreamed USP5 is no longer supported, I can change my setup accordingly and see if it helps.


Update:

Well, I tried it with a pure SP4 source and w2ksp51.exe in HF. There was no difference in outcome (going through a full installation). I also made a file-by-file comparison of the content of the resulting iso's (using Winmerge), and found that the only truly differing file was hfslip.log, that now listed w2ksp51 in the HF folder, and also mentioned that it was slipstreamed into the source by HFSLIP. (For the sake of completeness: bidibtrx.in_, dxbda.in_, swflash.in_, and sysoc.in_ were also different, but only because the identical .ini files contained within had different time stamps.)

I am planning to test some older HFSLIP versions to see if that would make a diffence.


Update 2:

I have now also tried 1.7.8, and the only difference seems to be that a couple other updates, for which support has since been added, are not properly installed.

So, I guess, that in a nutshell this just boils down to the latest ie6sp1 cumulative update (MS09-019 / KB969897) somehow not being fully installed.

This post has been edited by Inki: 15 June 2009 - 10:29 AM