File not marked as 'M' when contents differ from repo

[Emanuele Aina]

Matt Mackall considerò:

>>> Changes that don't change file time OR size OR mode are indeed not
>>> detected.
>> We in the git land call this "racy git" problem, and call such
>> files "racily clean".
>>
>> We have dealt with this problem by checking the contents of
>> potentially "racily clean" file whose timestamp match that of
>> the index [*1*].  After such a test, if such a "racily clean"
>> file is found to be modified, we drop the cached "size" field to
>> zero, so that later check with lstat(3) do not have to trigger
>> the contents comparison logic again.  The last trick of smudging
>> racily clean path takes advantage of the fact that a file with
>> 0-byte contents cannot have been modified if the size does not
>> change ;-).
> 
> Hmm, we've considered the first half of that approach (comparing
> against the dirstate timestamp), but I don't think we've considered
> the second half.

In a conversation with Rober Collins, a bzr developer, he told me they
don't add things to their hash cache if the files have been created in
the 3 seconds preceding the cache creation (this is due to FAT which has
2 seconds granularity).

It would be great to fix this race, as I've seen it mentioned around the
Web quite a bit.

-- 
Buongiorno.
Complimenti per l'ottima scelta.