Re: broken racy detection and performance issues with nanosecond file times

From: Karsten Blees <karsten.blees@gmail.com>
Date: Sep 29, 2015, 11:28 UTC
Message-ID: <560A75D4.9000206@gmail.com>
In-Reply-To: <xmqqbncme95a.fsf@gitster.mtv.corp.google.com>

Am 28.09.2015 um 19:38 schrieb Junio C Hamano:

Show 22 quoted lines

> Karsten Blees <karsten.blees@gmail.com> writes:
> 
>> Problem 1: Failure to detect racy files (without USE_NSEC)
>> ==========================================================
>>
>> Git may not detect racy changes when 'update-index' runs in parallel
>> to work tree updates.
>>
>> Consider this (where timestamps are t<seconds>.<nanoseconds>):
>>
>>  t0.0$ echo "foo" > file1
>>  t0.1$ git update-index file1 &  # runs in background
> 
> I just wonder after looking at the ampersand here ...
> 
>> Please let me know what you think of this...maybe I've completely
>> screwed up and can no longer see the forest for all the trees.
> 
> ... if your task would become much simpler if you declare "once you
> give Git the control, do not muck with the repository until you get
> the control back".
>

This is just to illustrate the problem. GUI-based applications will often do things in the background that you cannot control. E.g. gitk, git gui, Eclipse or TortoiseGit don't tell you when and how long you shouldn't touch the working copy. At the same time, IntelliJ IDEA and most office suits have the auto-save feature turned on by default, and you cannot tell them when *not* to auto-save.

It may still be quite unlikely that this happens (you need two changes within a second, without changing the file size), but *if* it happens, the user may not even notice. And as git trusts the false stat data blindly, the problem won't go away automatically. You can mark all entries racy by setting index mtime to some value far in the past, but this implies that you noticed that something was wrong...