Why don’t the file timestamps on an extracted file match the ones stored in the ZIP file?


A customer liaison had the following question:

My customer has ZIP files stored on a remote server being accessed from a machine running Windows Server 2003 and Internet Explorer Enhanced Security Configuration. When we extract files from the ZIP file, the last-modified time is set to the current time rather than the time specified in the ZIP file. The problem goes away if we disable Enhanced Security Configuration or if we add the remote server to our Trusted Sites list. We think the reason is that if the file is in a non-trusted zone, the ZIP file is copied to a temporary location and is extracted from there, and somehow the date information is lost. The customer is reluctant to turn off Enhanced Security Configuration (which is understandable) and doesn't want to add the server as a trusted site (somewhat less understandable). Their questions are

  • Why is the time stamp changed during the extract? If we copy the ZIP file locally and extract from there, the time stamp is preserved.
  • Why does being in an untrusted zone affect the behavior?
  • How can we avoid this behavior without having to disable Enhanced Security Configuration or adding the server as a trusted site?

The customer has an interesting theory (that the ZIP file is copied locally) but it's the wrong theory. After all, copying the ZIP file locally doesn't modify the timestamps stored inside it.

Since the ZIP file is on an untrusted source, a zone identifier is being applied to the extracted file to indicate that the resulting file is not trustworthy. This permits Explorer to display a dialog box that says "Do you want to run this file? It was downloaded from the Internet, and bad guys hang out there, bad guys who try to give you candy."

And that's why the last-modified time is the current date: Applying the zone identifier to the extracted file modifies its last-modified time, since the file on disk is not identical to the one in the ZIP file. (The one on disk has the "Oh no, this file came from a stranger with candy!" label on it.)

The recommended solution is to add the server containing trusted ZIP files to your trusted sites list. Since the customer is reluctant to do this (for unspecified reasons), there are some other alternatives, though they are considerably riskier. (These alternatives are spelled out in KB article 883260: Description of how the Attachment Manager works.)

You can disable the saving of zone information from the Group Policy Editor, under Administrative Templates, Windows Components, Attachment Manager, Do not preserve zone information in file attachments. This does mean that users will not be warned when they attempt to use a file downloaded from an untrusted source, so you have to trust your users not to execute that random executable they downloaded from some untrusted corner of the Internet.

You can use the Inclusion list for low, moderate, and high risk file types policy to add ZIP as a low-risk file type. This is not quite as drastic as suppressing zone information for all files, but it means that users who fall for the "Please unpack the attached ZIP file and open the XYZ icon" trick will not receive a "Do you want to eat this candy that a stranger gave to you?" warning prompt before they get pwned.

But like I said, it's probably best to add just the server containing the trusted ZIP files to your trusted sites list. If the server contains both trusted and untrusted data (maybe that's why the customer doesn't want to put it on the trusted sites list), then you need to separate the trusted data from the untrusted data and put only the trusted server's name in your trusted sites list.

Comments (35)
  1. Jesse says:

    I'm not sure if I entirely follow this.  It sounds like from the customer's description that it's not the ZIP file's "Last Modified" date that is problematic, but the "Last Modified" date of the files extracted from the archive.  But your explanation has to do with modifying the "Last Modified" date on the archive itself.  Does the Explorer archive extractor use the archive file's date in determining what to set the extracted file's dates to?  I was under the impression that ZIP archives included the ability to store the "Last Modified" timestamps per file.

    [The file is extracted with the timestamp as recorded in the ZIP file, then it is modified to add the security zone information. -Raymond]
  2. Alex Grigoriev says:

    Or how about fixing zipfldr.dll, to make it set the timestamp on the files _after_ applying the zone information? Or making the "set zone information" function preserve the timestamp?

    [But doesn't changing the security information on a file constitute modifying it? -Raymond]
  3. Fred. says:

    [But doesn't changing the security information on a file constitute modifying it? -Raymond]

    No. No more than renaming it does at any rate.

  4. Paul says:

    @Fred

    Wrong answer.  You've just substituted one problem for another ("why did the OS apply the zone identifier to the executable and not change the time/date?   How am I meant to know if the file changed or not?")

  5. Yuliy says:

    I think the customer is using modified timestamp to mean "when was the content stored in this file modified". However, Windows treats it as "when was the file or its metadata update?" This is what caused the problem. The user's expectation of the semantics of modified timestamp didn't match the OSes definition of those semantics.

  6. Cesar says:

    [But doesn't changing the security information on a file constitute modifying it? -Raymond]

    It doesn't. That security information is metadata. It is much like changing the file permissions or the file owner, which should not change the file's mtime either.

  7. Cesar says:

    As an aside: it seems preserving this zone information is yet another of these "taxes" (blogs.msdn.com/…/454487.aspx). Do third-party unpackers even think of preserving it? And is there a list of these "taxes" anywhere so software developers know what to pay attention to? It could be a very useful resource (at least for the kind of software developer who would follow this blog).

  8. Alex Grigoriev says:

    [But doesn't changing the security information on a file constitute modifying it? -Raymond]

    By that reasoning, the unzippers would have never set the original timestamp on the unpacked files, because THEY JUST CREATED AND WRITTEN THEM. And the shell file copy function, too.

    But no, they take pains to set the desired timestamps. And the function that ZIPFLDR.DLL uses to save the files does set the timestamps explicitly. It's just the small issue of applying the additional stream to the file afterwards, that screws them.

    I'm not sure why you're trying to advocate this is a proper behaviour, rather than a bug.

  9. Joshua says:

    @Cesar: I deliberately write my tools to strip the security zone information.

  10. dave says:

    There could be timestamp for "the contents of the file were changed", and a timestamp for "the file's metadata was changed".

    There could, but the zone information is "contents of the file" as far as the file system is concerned.

    Don't forget, a "file" is a bundle of data streams (one of which is The Stream With No Name), and the zone info is just another data stream.

    Your app could store most of its data in a named stream too, if it wished.

    (I think the fundamental issue here is that NTFS deviated too far from 'normal user expectations' with alternative data streams.  Compare OS/2 'extended attributes', which are arguably the same concept, but which name carries an implication that it's 'attributes' not 'data')

  11. Cesar says:

    @dave: if the zone information is part of the "contents of the file", then the unpacker is modifying the contents of a file it unpacked, which is just completely wrong.

  12. Random832 says:

    "There could, but the zone information is "contents of the file" as far as the file system is concerned."

    So is the actual contents, but the fact that it just went from an empty file to however many bytes extracted from the archive just a second ago doesn't normally pose a serious ontological dilemma for an unzip tools' application of the stored timestamps immediately afterward. This isn't the posix ctime – this is here for the user, not to meet some rigorous definition of "modified".

  13. dave says:

    There could be timestamp for "the contents of the file were changed", and a timestamp for "the file's metadata was changed".

    There is in NTFS, almost.

    Last write time = time file's contents changed.

    Change time = time file's metadata or contents changed.

    (See File System Behavior Overview document, findable with Google, which is aimed at protocol implementers more than users)

    'Change time' is not exposed through the Windows API, as far as I know.

  14. jon says:

    Yes, modifying the file metadata modifies the file timestamp, Raymond is perfectly correct from a technological point of view.

    However, this is completely wrong from the user's point of view. The user doesn't care about the mechanism of implementing the zone check. There's absolutely no reason, from the user's point of view, that the timestamps should be changed. It just makes it look like a bug, which frankly, it is.

    Unfortunately, far too many design decisions in Windows (particularly the shell) are made from the point of view of the developers, to make things easier for them. This is just another example.

  15. John says:

    "[But doesn't changing the security information on a file constitute modifying it? -Raymond]"

    Conceptually, "security information" is an attribute.  Does setting the read only or archive attributes change the timestamps?  I would expect those actions to have the same behavior.  I don't recall the semantics of alternate data streams, but perhaps this is just a leaky abstraction.

  16. Ens says:

    @Cesar

    It's modifying the contents of the file to write the zone information, and it's not wrong to modify the contents because the contents is where the zone information data is stored.  The weird piece in all of this is that zone information "feels like" metadata but it's stored as a stream.  And it's especially weird because the system takes pains to make sending zipped files "feel like" a straight file copy from a metadata standpoint, when it isn't really, so there's precedent already for holding the metadata constant.

    I think with a time machine we might have per-stream "last modified" times, so that streams which encode pseudo-metadata like the zone identifier could be ignored or not ignored as the consumer desires.

  17. Christian says:

    [But doesn't changing the security information on a file constitute modifying it? -Raymond]

    Oh, I got that, that's an simple one: No, it does not. The zip code simply has a bug: It must add the zone information in a way where it doesn't modify the extracted time.

  18. Mike B says:

    Couldn't the customer also unblock the file to strip the info (right-click the zip, hit unblock), then unzip the file?

  19. David Walker says:

    Ack, I hope this isn't a double-post.  My last one went away.  Here goes again…

    There could be timestamp for "the contents of the file were changed", and a timestamp for "the file's metadata was changed".  And a timestamp for "the file was moved from one folder to another".  That doesn't change the file's "last modified" date, since the file's location is not really an attribute of the file itself.

    But then, reading a file's metadata to read the last accessed timestamp is not counted as an "access" of the file.  So that's a special case.  Otherwise, the last access time of a file would always be *right now*.  I'm just accessing the file to see when it was last accessed, but this access doesn't count.

    So, you could make a case that changing the file's security zone information does not count as a modification to the file.  After all, it's an attribute of *where the file came from*, not anything intrinsic to the file itself.  Similar, perhaps, to a file being moved from one folder to another, which doesn't change a file's last modified timestamp.

    Yes, computers are hard.

  20. Cheong says:

    @Mike: Because that'd require the user to copy the ZIP file to a local location instead of opening the file directly.

    I think a possible workaround would be to create a special rule (whether as a general implementation or as a GP rule) that changing zone information won't modify timestamps.

    P.S.: In the past when a POST somehow unsuccessful, the comments would be preserved. But now when the POST is unsuccessful, the comments are gone! Oh… I've forgotten what I typed in the second paragraph.

  21. Cheong says:

    Argh right… I have a problem recognize why adding the remote location to a trusted zone would be consider risky. Afterall you're going to open ZIP files there… and if you use any 3rd party tools to automate the process later, you  won't get the zone information changed anyway…

  22. Cheong says:

    Argh right… I have a problem recognize why adding the remote location to a trusted zone would be consider risky. Afterall you're going to open ZIP files there… and if you use any 3rd party tools to automate the process later, you  won't get the zone information changed anyway…

  23. Gabe says:

    I just unblocked a file using SysInternals' streams.exe and Win7 Explorer. Neither one changed the modification time on the file. If unblocking a file doesn't change the modification time of a file, I wouldn't expect that blocking the file would change the timestamp.

  24. Crescens2k says:

    Gabe: Instead of unblocking try the following at the command prompt (elevated command prompt required).

    fsutil file createnew test.txt 0

    fsutil file createnew test.txt:stream 0

    Possibly leaving it a bit between the two operations to make the difference noticable. Or to make it possibly even more noticable

    fsutil file createnew alreadyexistingfile.txt:stream 0

    Then compare it with the file's original modified time.

  25. Gabe says:

    Crescens2k: I'm not talking about the specific act of modifying streams on a file; I'm talking about the abstraction of security zone annotations on files. Why should the act of blocking a file change its timestamp (particularly since no bits of the file change), when unblocking doesn't? And since the user didn't specifically act to block the file (i.e. the user can't see the file before it's blocked), there's no expectation that anything actually changed. As far as the user was concerned, the file was born with the block.

    I know that how it works is that adding or modifying a stream sets the file's LastWriteTime and ChangeTime (POSIX equivalent of mtime and ctime), while deleting a stream sets only the file's ChangeTime.

    I also know that zipfldr.dll writes the file, sets the timestamp, closes the file, and then as a completely separate operation calls into shdocvw.dll to set the zone identifier. I would argue that either zipfldr should make a special case and set the timestamp again after setting the zone ID, or shdocvw should save the file's timestamp and restore it after setting the zone ID. Afterall, if you're not changing the bits in the file, you shouldn't change the LastWriteTime.

  26. NB says:

    Can't you bypass this problem by using a 3rd party zip-program instead of the one built-in Explorer? Say 7-zip for example?

  27. Chris Nahr says:

    "Can't you bypass this problem by using a 3rd party zip-program instead of the one built-in Explorer? Say 7-zip for example?"

    Bingo.  None of the third-party packers I used (7-Zip, WinRAR, Speed Commander) copy those security annotations from an archive to extracted files, and I've certainly never missed them.  It's an ill-conceived feature to begin with — one warning for the archive itself should be enough.

  28. GWO says:

    The key question is "Should modifying the file metadata update the file-modified flag", and the answer is "Whichever you choose (yes, no or 'it depends which metadata'), reasonable people may disagree with you."

  29. Neil says:

    Perhaps the customer should unzip the files onto a FAT drive.

  30. Paul says:

    This reminds me of an old annoyance:

    Last Accessed time. You access the file to retrieve that. Last accessed = now.

  31. Medinoc says:

    Jesse wrote:

    Or how about fixing zipfldr.dll, to make it set the timestamp on the files after applying the zone information?

    If they to, they should also fix the problem of zipfldr.dll apparently not respecting SHSetInstanceExplorer…

    ( blogs.msdn.com/…/8555658.aspx )

  32. David Walker says:

    @Paul:  Yes, that's just what I said.  :-)

  33. Mark says:

    Cheong: they don't say that need to open it directly, merely that copying from the remote server fails, but if copying it locally through some other means doesn't.  I think the correct response to the customer should be "we'll fix/patch zipfoldr.dll", but until then, just hit Unblock, or use this .vbs file, or use a different extraction program.

    zipfldr.dll is an awful example of Windows developers not paying any of their taxes.  It doesn't even disable the 'Next' button when extracting – I wonder how many bugs have been raised for that alone.

    The last access time thing has been brought up to the point of tedium.  It is useful for determining what can go to slower storage (e.g. tape backup).

  34. Paul says:

    @David Walker: I missed that, or skimmed. Rereading, I think I'm thinking of an old problem then.

    I remember getting the last accessed time on Windows 95 DID get the current time (less a second or so on the school machines due to network lag!) since it accessed the file to get the information on file access.

  35. Troll says:

    Sadly Microsoft is to blame here as they rolled out Attachment Manager in XP SP2 without a PROMINENT way to turn it off (Group Policy isn't even in all Windows editions). Usually, the GPO to disable the Attachment Manager (Do not preserve zone information) that I apply right away after reinstalling Windows. I fear worse changes coming in Windows 8 with extremely slow IE9-like SmartScreen checking also baked it to further spoil the experience.

Comments are closed.

Skip to main content