I have replicated this issue using a default install of 4.4.1, removing all modules except the Welcome... module, and running SQL Profiler. Firing up the debugger and walking through PortalModuleBase - CreateChildControls method, I encountered some very strange behavior with the code below:
Dim cacheFile As New FileInfo(CacheFileName)
If cacheFile.CreationTime.AddSeconds(_moduleConfiguration.CacheTime) >= Now Then
...
When I examine the value of the CreationTime for the cacheFile sometimes contains a date/time which is not correct. For example, lets say we have a cacheFile which has a date of Jan 19, 2007 1:00 PM, our module has a CacheTime of 60 seconds, and the current date/time is Jan 19, 2007 2:00 PM. The code above determines the cacheFile to be "expired" so the code in the CreateChildControls method deletes the file from the file system ( I even verified in File Manager that the file was deleted ). Then the Render method creates a new version of the file ( which I also verified in the File Manager ). However, on the next request, when the debugger hits the code identified above, the CreationTime is still set to Jan 19, 2007 1:00 PM - the date/time value of the old version of the file which was deleted! In File Manager, when I right-click and view the file properties, it also displays a CreationTime of Jan 19, 2007 1:00 PM. So it appears that Windows is caching the CreationTime of the file and when a new file is created with the same name, it uses the cached CreationTime. This obviously leads to some weird behavior. But its not surprising, as we found a similar Windows bug when we were working on the folder synchronization logic ( when a file is replaced with a newer version, the Directory LastModifiedDate attribute is not updated to reflect this change ).
After looking at the other attributes available and confirming their reliability, it appears that we should actually be using the LastWriteTime for the cacheFile - as it appears to always be accurate in terms of its value.