Re: Handling racy entries in the v5 format [Re: [GSoC] Designing a faster index format - Progress report week 7]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 6/6/2012 11:45, schrieb Thomas Rast:
> Proposed Solution
> -----------------
> 
>   When writing an entry: check whether ce_mtime >= index.mtime.  If so,
>   write out ce_mtime=0.
> 
> The index.mtime here is a lower bound on the mtime of the new index,
> obtained e.g. by touching the index and then stat()ing it immediately
> before writing out the changed entries.

Portability note: To "touch" on Windows will mean that the file is
modified (at least one byte is written), then closed. Only then the stat
information is reliable. The reason is that the time stamp is only valid
after (the last handle of) the file was closed.

> Note that this is a fundamentally different approach from the one taken
> in v[2-4] indexes.  In the old approach, it is the *next* writer's
> responsibility to ensure that all racy entries are either truly clean,
> or smudged (since they will presumably lose their raciness).  In the new
> approach, racy entries are immediately smudged and remain so until an
> update.

-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]