File timestamps apparently ignored

[random]

Hello,

I thought that my files that were previously downloaded (and thus on DVD/CD, in my case) would be preserved the next time I ran wsusoffline, but it didn't. Even though the original file timestamps are present, the selfsame files are downloaded over and over again. Is it only me? is it by design? Has it got to do with MS servers?

Actually only few files aren't re-downloaded. The ones dynamically determined are all re-downloaded regardless their timestamps.

What I would like to do is something like a differential update to my DVD's.


Thank you very much.


random

[aker]

Please post the content of .\log\download.log.

wsusou should just download the newer / changed files.

There is a known problem with the MS servers, when downloading the Windows Defender / MSSE definitions, but all other updates should be downloaded once.

[boco]

Rootsupd lately has that issue, too, but it's too small to be noticed.

[random]

Hi all,


Well, I think I found out what the problem is. I suspect that the problem is the mkisofs utility that somehow is reseting or changing the attributes/timestamps of the files. But what intrigues me is that for some files that problem doesn't occur at all. Have a look-see:



I think that long file names like:

ie11-windows6.1-kb2909210-x86_040c5245b3493eec0d9febccd59949229258e632.cab
windows6.1-kb2705219-v2-x86_527be4aa29d9d8a20d8762a204cb65749b9c546c.cab
etc.

might be the culprit. I'm not sure about this. But since all dynamically determined downloads are affected by this problem, it may be pointing out in this direction. Could it be the command-line switches of the mkisofs?


So, to test this, I RARed all the directories of interest (dotnet, w61, etc.), deleted them afterwards, unpacked the archive and restored the contents of the directories. Now it works. The updates don't get re-downloaded as before. I tested copying to a flash drive and didn't have problems either.


@boco: I had noticed that too..


So, what do you think?

regards,

random

[aker]

The long filenames are normal.

[boco]

The long filenames are normal.

Of course. The hint was that mkisofs could have a problem with such long paths, somehow. Usually these type of utilities try to reset the Archive attribute of the files. Although that can be configured and shouldn't touch (=change modification time) any files, it might be the rule is ignured for long filenames (maybe due to a bug with long paths).

@OP: Might be another possibility - Could you check if you have short filename creation on the drive enabled/disabled?

As for the redownloads, wget always does that if the sizes of local vs. remote files differ. Any timestamps will be ignored in that case.

[random]

Hallo,

@OP: Might be another possibility - Could you check if you have short filename creation on the drive enabled/disabled?

Are you referring to this entry: NtfsDisable8dot3NameCreation? If so, the value of this entry is set to 2, which is the default value in Windows 7.

http://support.microsoft.com/kb/121007

As for the redownloads, wget always does that if the sizes of local vs. remote files differ. Any timestamps will be ignored in that case.

Yes, I'm well aware of this..




Thanks.

-random

[boco]

If it is set to 2, check the value for the volume in question.

[random]

OK.

Here you go:



That is,

The volume state for Disable8dot3 is one (8dot3 name creation is enabled).
The registry state of NtfsDisable8dot3NameCreation is 2, the default (Volume level setting).
Based on the above two settings, 8dot3 name creation is enabled on C:.

regards,

random

[boco]

OK, we can forget about the short names.

Does your WSUSOU reside in a deep path?