[ccache] PATCH: Look at include files' mtimes

[Justin Lebar]

> I've been burned by mtime only checking before as
> (excluding some recent file systems) mtime has a resolution
> only down to one second.

I tried to address this in the patch, although come to think of it, I
did it wrong.

The trick is only to *cache* mtimes that are at least one second older
than now.  Then the resolution of the clock isn't a problem.

But if the system clock is set back (e.g. by NTP), we're in trouble.
And hardlinks are often created without bumping the inode's mtime,
which is also problematic.  (It's problematic for make, too.)

So I tend to agree that this should be off by default, unless we have
some brilliant way of detecting system clock changes.

I can't say I'm particularly interested in supporting two manifest
versions simultaneously, but that's up to Joel.

-Justin

On Mon, May 21, 2012 at 9:43 PM, Wilson Snyder <wsnyder at wsnyder.org> wrote:
>
>>This patch lets ccache examine an include file's mtime and size in
>>lieu of hashing it, during direct mode.  If the mtime and size don't
>>match, we fall back to hashing.
>>
>>The net result is roughly a factor-of-two speedup in ccache hits (*),
>>on my machine.
>>
>>I'm not sure if this is a desirable feature, because obviously mtimes
>>can be tampered with.
>
> IMO I at my site I would be reluctant to use ccache with
> this enabled, and believe the default should be as safe as
> possible. I've been burned by mtime only checking before as
> (excluding some recent file systems) mtime has a resolution
> only down to one second.
>
> However including it as an option seems fine, and recording
> it into the manifest also seems good.  I would also suggest
> making the manifest format backward compatible when it is
> easy as in this case; just test the version number when
> reading the file.