I have some macros in VbaProject.OTM. Once in a while, I update the code, but the timestamp does not change. I did not check whether the file size changes.
This, this and this report similar observations.
Is this behavior expected?
If not, any idea on what could the problem be?
The first link above shows a couple of workarounds, but I meant to understand the cause for this, and to find a solution to revert this behavior (if possible), instead of workarounds.
It gets better. None of the "tell me when a file changes" features in Windows, namely FindFirstChangeNotification() and ReadDirectoryChangesW() will report when the file is saved, unless the size changes, and that doesn't happen unless a lot of code is added. I just had to drop in 64 K of comments to get it to change.
procmon shows write operations, but there is no operation to change the time stamp. I don't quite get how they manage to keep the file time the same when the default behavior is to update it every time the file is written to.
This is not just a problem when you want to distribute macros by distributing the file (which you really shouldn't, Microsoft is correct there; the internal structure of the file might change with Outlook versions or even individual updates). It is also guaranteed grief when you reinstall or move computers and find out too late that the copy in your roaming user profile is ancient ...
My personal workaround is to have something in Startup that touches the file. That way, it's always copied.
The cause, btw, is either of the two mentioned at http://blogs.msdn.com/b/oldnewthing/archive/2011/08/12/10195186.aspx. Outlook is using memory-mapped IO, and it may well also do the SetFileTime() thing; I'm not sure if procmon would see that.
None of the following appears to be documented, but based on the experience collected from posts already listed in the OP. More solid information might be posted.
Is this behavior expected?
No. This is quite different from what many people would expect.
If not, any idea on what could the problem be?
It appears that this behavior is standard in Outlook (i.e., not something that I see in my system due to configuration issues). So, the "problem" is how Outlook is designed.
... I meant to... find a solution to revert this behavior (if possible)...
There appears to be none.
... instead of workarounds.
As mentioned here and in the OP.
PS: Since none of the two workarounds proposed appear to be options in some cases, one may try to write a macro that would execute a shell command with touch ... (or the like), to set the modification time. It will likely find that VbaProject.OTM is in use, so one would have to deal with that too. Not a trivial task.
From This which you linked to includes two ways to resolve this issue:
Do neither of those work? If not, you might suggest in your question why these methods will not work for you, so that other suggestions may be forthcoming.
