Detection Method of Date Modified fails due to copied files date modified change

Question

I've been working through an issue for some time now and I think it's a bug with SCCM 2012 SP1. I've built literally 50 deployments in "Application Management" in SCCM 2012, but I've been chasing my tail on a few of them throwing the
"succeeded but couldn't detect" error. The few that have given me problems are all copying text files and then detect the modified date to verify that the file is there. All worked when I initially built them in Windows 8 but are now failing
randomly...even on a machine where they previously worked and I deleted the files to test the deployment again. 
What I'm doing:
My java deployment requires policies which we control with the Deployment.config, deployment.properties and java.policy files. A simple script creates the directories and copies the files. I then create a deployment type for this "ConfigFileCopy.cmd"
and create a detection rule for each file that I am moving over. The detection rule looks for a "date modified" date between the beginning and end of the date for the day I modified the file. This allows me to modify the files to change our
java policies and then redeploy them with the "new" modified date as the detection rule, which forces the update.
The problem:
When I first created my deployment, everything worked pretty well. The files copy out and the script runs successfully. There were some minor tweaks I need to make to my scripts, so I did and then updated the content for the deployment type. I believe this
is where things go a little wonky. At this point, my deployment starts failing with the "0x87D00324" error.
Looking through the logs, everything looks good. The reason configuration manager is failing on detecting the modified date for those files, as it turns out, is because the modified dates don't meet the criteria. So that part is properly failing the detection.
The problem is that the modified dates are correct on the server but not the client. Looking in c:\windows\ccmcache, I can see multiple folders....presumably one for each version of the application that I updated. Looking at any of the newer content folders
for this app, the modified dates are the date and time the file was copied out to the workstation, which is incorrect as the file hasn't been modified during that process.
The odd part, is that this doesn't happen EVERY time on EVERY machine. My primary desktop is windows 8.1 and received the files correctly and installed without issue. My test win 8.1 laptop initially received them correctly, but then as I refined the scripts
it began picking up the wrong modified dates and started failing.
I found a similar issue to this existed in SCCM 2007 (http://support.microsoft.com/kb/2276865) so I suspect that this is truly just a bug that hasn't been addressed (or maybe is fixed in R2). Unfortunately
we have business reasons we can't upgrade to R2 at this time so I'm hoping someone has experienced this and has some sort of work around that might get me by for now. If someone can confirm it is fixed in R2, that would help my case to upgrade as well.  
I can work around the issue by changing my logic to detect any date greater than a specific date. But I shouldn't have to do that and I'm concerned there are scenarios I haven't thought of that will cause unexpected behavior or failures with that.
 

Answer 1

This outlines the behavior. It's apparently by design. 
"SCCM has a habit of changing the ‘Date Modified’ timestamp of all files it delivers when it detects an ‘upgrade’ of the source files for that application. It typically does not touch the timestamp
of the source files if it delivers a brand new install to a client that has never received the software, however if a single file in the source folder is changed for that application, then SCCM tries to use a previous version of the application in the cache
(C:\windows\ccmcache) and only downloads the new file that has change. This results in all files having their ‘Data Modified’ timestamp changing (except for the brand new file). Therefore determining if that application has delivered
successfully using ‘Date Modified’ timestamps is not recommended. The key to seeing this process in action is looking at the file properties in the
C:\windows\ccmcache\<sccm code> folder for that application, particularly before and after a file is updated in the original source SCCM application folder."
http://blog.kloud.com.au/tag/sccm/