Modification date on an executable file is changed when copied to another folder

A. THE BUG/ISSUE (Varies from issue to issue)
Can you reproduce the problem & if so how reliably?:
Yes, very reliably, so far on a physical machine and 2 different VMware virtual machines.
If you can, exact steps to reproduce. If not, exactly what you did & what happened:
1:Copy an executable file from one folder to another. Please note that data files of various kinds and .dll files are not affected. So far, I’ve only seen this bug affect the copying (not moving) of executable files. The file I just now copied is “cis.exe” from the folder “C:\Program Files\COMODO\COMODO Internet Security” to my Documents folder. The original file is build 4591 and carries the file date 6/5/2015, and the new copy in my Documents folder now carries the file modification date 8/5/2015 (today’s date). Of course, this particular file is from Comodo, but virtually any executable file on the computer exhibits the same file date corruption during the copy operation. Every copy operation should always maintain the modification date.

One or two sentences explaining what actually happened:
A very important piece of metadata normally maintained by Windows has been corrupted by a simple copy operation. Uninstalling Comodo CIS totally alleviates this problem, and reinstalling it brings back the same problem.
One or two sentences explaining what you expected to happen:
Having conducted this test with several previous v8 builds with the same results, this was what I expected to happen, but definitely not what should have happened.
If a software compatibility problem have you tried the advice to make programs work with CIS?:
Besides my regular computer which has over a hundred programs installed and many potential conflicts, I’ve reproduced this bug on near-virgin Windows 7(SP1) and Windows 10 virtual machines.
Any software except CIS/OS involved? If so - name, & exact version:
No apparent conflicts except with the operating systems themselves (Windows 7 and 10).
Any other information, eg your guess at the cause, how you tried to fix it etc:
My best guess is that some low-level module in CIS is (naturally) paying very close attention to executable files as a primary source of infection, and CIS inserts itself into the copying process where the modification date is not properly maintained through one of the steps.

Exact CIS version & configuration:
Any of several builds of CIS version 8, most recently v8.2.0.4591.
Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV:
I’ve done this with only AV and also with only Firewall, in both cases with default setup configuration. However, when I first discovered the bug, it was when I upgraded my regular computer from v7 to v8 of Comodo and imported the old configuration. So I’ve seen this behavior exhibited through a broad range of configurations.
Have you made any other changes to the default config? (egs here.):
I purposely installed the minimum possible AV default configuration, and later I tried again with just the Firewall default configuration. Both minimum installations evoked the dreaded bug.
Have you updated (without uninstall) from CIS 5, 6 or 7?:
I upgraded my regular computer from v7 to v8. As soon as I traced the buggy behavior back to Comodo, I regressed to v7, the buggy behavior disappeared, and all further testing has been on VMware virtual machines.
if so, have you tried a a a clean reinstall - if not please do?:
Yes, I did a completely clean install on Windows 10. The other machines had whatever traces of CIS that may remain after completely uninstalling the program.
Have you imported a config from a previous version of CIS:
Yes, and the bug appears whether the configuration is default or imported.
OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:
Windows 7(SP1)-64bit and Windows 10-64bit, both in near-virgin states (especially for testing new software).
Other security/s’box software a) currently installed b) installed since OS, including initial trial security software included with system:
No other security software installed.

Hi and welcome to the forum,

This issue is caused by the File Source Tracking in CIS, it was introduced in version 8 and works by modifying the ADS (Alternate Data Streams). It’s purpose is to add source information which helps the Auto-Sandbox in CIS to determine if it should be sandboxed or not, this is to reduce the amount of unknown executables that are sandboxed while still providing good protection. A side effect of modifying the ADS is that the modified date also changes.

If you want to change this behavior then you need to go to the advanced settings in CIS then Security Settings > Defense+ > Sandbox > Auto-Sandbox and deselect “Enable file source tracking”. This will stop CIS from modifying the ADS of files however it won’t remove already created ADS from files.

Wow, Sanya, thanks so much for the quick and knowledgeable response. Done, tested, and working! I’ve been using CIS v7 all this time because of the modification date issue on v8, but with an upgrade to Windows 10 on the near horizon, version 7 is no longer an option. Thanks again.

This just in, concerning these unwanted modification date changes… I just now did an in-place update to build 4674 on Windows 10 in my virtual machine. The source-tracking function of the auto-sandboxing feature which had been disabled in the pre-update configuration was automatically re-enabled in the update process, so apparently this will require vigilance for users who don’t want those executable file dates changed.

One more thing, expanding on how this affects typical users. I purposely used a relatively atypical example in my bug report to show the most direct possible connection between Windows and Comodo when the modification date is changed on executable files. Most people don’t copy executable files the way I did. However, there are much more common scenarios where these dates will also be changed by CIS source-tracking. A better example is this… I just now extracted an old printer driver installation file from a Zip archive, using WinRar. The driver has a modification date from 2009, which clearly shows inside the archive. Under the hood, WinRar reconstructs the file in a temporary directory and then copies the reconstructed file to your chosen extraction target. So after extraction, instead of the original modification date from 2009 which WinRar always preserves, my driver has been magically updated to today’s date, looking deceptively fresh. The reason, of course, is that CIS secretly hooked into the copy process and created an alternate data stream (ADS) containing file source-tracking information, triggering Windows to change the file’s modification date, even though the primary data stream of the file remains unchanged.

This behavior may be considered a feature, but it’s certainly one with an unwanted side-effect, and my primary beef with it is that this side-effect is not disclosed in any way (until I saw Sanya’s excellent response to my bug report), and it takes a relatively deep dive into the configuration options to disable it. But I do see the value of the feature, so I’ll temper my criticism with that, but I’ve still chosen to always disable it. There are still many ways in which I consider CIS to be excellent, and the ability to turn off this one small feature shows off CIS’s highly configurable nature.


Since this is not technically a bug but an adverse affect of the method of file tracking comodo is using i will move this to resolved.

Thanks again Sanya for your help