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.
B. YOUR SETUP
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.