Windows 10: W10 changes timestamps on executables after running them. Normal?

Hello.

I don't know where to post this. It's getting me crazy. Running w10 x64 and quite satisfied with it.

I usually do a "synchronize folders" within Total Commander for doing a differential copy of regular applications I download and use. Anyway, I have found out that TC insists on some files being "different" or "changed" after I have ran them. I have found out w10 "automagically sets" current date and time to the executable file after it has been run. Is this normal? Or is it Windows Defender who does it?

A little annoying in my opinion. Ideas?

:)

 

Does Nokia N9 work with Ovi Sync?

Hi. In my case, it's working only once, that is a day after I bought this phone (after checking timestamp at Ovi Contacts website). Clicking "sync" to execute the process manually doesn't work. Any suggestions?

 

Windows 10 BUG - NEEDS FIXING NOW!!!

Since there appears to be some confusion about this bug, I will fully explain the problem and how Microsoft can solve it.

The Problem and Its Cause

The root of the problem is alternate data streams (ADSs) in the NTFS file system, which store hidden data about a file. When you download a file from the Internet, a special ADS of that file is set ("Zone.Indentifier")
to indicate that the file came from the Internet. This allows Windows to detect when you try to open a file from the Internet and display a warning.

To allow you to freely open the file, the Zone.Indentifier ADS can be modified or removed. Removing an ADS does not appear to cause any change in a file's modification timestamp. However, modifying or adding an ADS causes the main file modification timestamp
to be updated. (I consider this to be a poor design decision of NTFS because the actual file content did not change, only a data stream that is never presented to the user and changed without the user's knowledge.)

Windows changes the Zone.Indentifier ADS of a file whenever you:

A. Explicitly choose to "unblock" a file from the file's Properties window

B. Run an executable file

Prior to Windows 10, Windows would eliminate the Zone.Indentifier ADS by simply removing the ADS. This does not cause a change in the timestamp.

In Windows 10, Windows now modifies the Zone.Indentifier ADS rather than simply removing it. Since modifications to an ADS change the main file's modification timestamp, this causes the file's timestamp to change to the current time. Thus,
Windows is incorrectly changing the modification timestamp of the file even though neither the user nor the system made any changes to the user-accessible file content.

Related Bugs

The modification of ADSs causes the incorrect modification of file timestamps for various operations. Here are the ones that I have noticed:

1. Explicitly choose to "unblock" a file from the file's Properties window

2. Run an executable file

3. Extract a ZIP file with Explorer that has a Zone.Indentifier ADS indicating it was downloaded (the extracted files will all be set to the current time) [reference]

4. Allow Windows Search to index an EML or NWS file for the first time [reference]

How to Reproduce

1. Download an executable file using Internet Explorer from a standard Internet site (not in a trusted "security zone"). (This will probably work for all other browsers.)

2. Go to the file's Properties window and note the "Modified" time.

3. Wait at least a minute for the system time to change.

4. Run the executable file, or choose to unblock it from the Properties window.

5. Reopen the file's Properties window and note that the "Modified" time has been changed.

You can also find instructions to reproduce the related bugs for
ZIP files and
EML/NWS files.

How Microsoft Can Fix This

I can think of several solutions that Microsoft can implement with varying levels of difficulty:

1. [Easiest Fix] Before modifying/adding an ADS, have Explorer save the file's current modification timestamp (GetFileTime). Then restore the original timestamp (SetFileTime) after the operation is complete.

2. [Partial Fix] Remove the Zone.Indentifier ADS (as in Windows 7-8.1) instead of modifying it (as in current Windows 10). Note that this will not fix the related timestamp bugs for ZIP files and EML/NWS files.

3. [Hardest Fix] Alter the NTFS API so that modifying/adding an ADS does not change the main file modification timestamp. This would fix the root of the problem, but it has compatibility implications.

 

Generally the only time you should see the time stamp change for any file would be when editing it like resaving an archive once files are added or when copying files around. The copy will see the new time stamp automatic at the time it is created during the copy process. Apparently 10 is resaving the files it opens up as it goes along.

Normal? Not that I know of? Useful at all? Could be for troubleshooting purposes at some point to which files were accessed when. That wouldn't anything dealing with WDefender however since that simply detects malwares and doesn't have any other control but to quaranteen or delete not change properties. Upgrade to 10 type of install I presume! Upgrades can be "buggy" in various ways!

 

Hello. Thank you for your reply. This is a clean w10 installation from scratch. I even bought a license for it.

It's not a big deal but it's puzzling me.

 

Typically .exe files creation dates only changes after they are compiled. That's the only way you can re-write an exe file.

 

I am talking about date/time shown on File Explorer. Maybe that's different than compiled date. When binary comparing the two pair (altered and not altered) they are byte identical though.

 

I just checked several exe files that have been used today and the date/time is the original prior dates, not today. Could it be that Total Commander is doing something to them? Does is monitor the files in real-time somehow? If so, I would disable the process and see if that changes what you're seeing.

 

I use both Total Commander and PowerDesk [on different computers] and both do have a function to change the Attributes of files, one of which is the date and time, but both programs need to have that function manually selected to accomplish the task.

 

The mention of you syncing files, folders seems to be the most likely reason. If the sync is online you are likely seeing the files refreshed each time you log into the game servers if no other local files are seeing this as well. The game apparently downloads temp files used during game play which are then replaced with each new gaming session. That would explain why you are seeing this type of time stamp alteration.

 

The sync is offline between a folder in my hd and an usb device. And it isn't games. It's my collection of utils (AV progs, etc).

 

To add some more weirdness. I have just run AdwCleaner from both Windows Explorer and TC and it didn't change anything. Maybe it's a bug in TC's sync feature. I will keep testing.

 

I am almost pretty sure it happens when any AV puts an executable in quarantine and you release it. It happened again with an executable quarantined in the destination usb drive by Panda Antivirus. It had its date updated for the time when it was scanned by the AV. I guess all AV programs do this then.

I am still investigating though.

PS - That was on a Windows 7 machine, just to clarify.

 

Is the executable part of a regular program or stand alone app? I have one old game title VIPRE loves to see the main exe file locked up repeatedly despite adding it to the exceptions list. Never saw any time stamp change however.

In fact I checked it now and it shows August 10, 2015 when I saw the clean install replace the pooched upgrade I ran with for the first week. For some reason the newer 2016 beta as well as the 2015 versions saw it as a bug while the 2014 never saw that come up.

While I suspect restoring something might be the av program simply copying it back to the drive I doubt you see numerous files each with their own time stamp changed thar were never locked up but possibly being backed up and restored in some manner. If the av program should happen to modify not copy particular files that would account for some seeing this. In years past AVG would clean files that got buggy back in the XP days however.

 

I think I have may nailed it down to those antimalware software that uses AutoIT.