Re: [PATCH 2/2] read-cache: use time_t instead of unsigned long
- From
Carlo Arenas <carenas@gmail.com>
- Date
- Nov 13, 2018, 09:10 UTC
- Message-ID
- <CAPUEspgqUZ9eKAGug=SGRedR=KBQswpsTZU+0PYHdGsCA4iZLA@mail.gmail.com>
- In-Reply-To
- <nycvar.QRO.7.76.6.1811130948420.39@tvgsbejvaqbjf.bet>
On Tue, Nov 13, 2018 at 12:49 AM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 5 quoted lines
> On Mon, 12 Nov 2018, Carlo Marcelo Arenas Belón wrote: >> > > if time_t can't represent a valid time keep the indexes for failsafe > > Is this sentence incomplete? What are those "indexes"?
the indexes that are created when core.splitIndex = true
the code that was modified looks for a configuration parameter (or the default) that says something like "2 weeks ago" and that then converts that into a timestamp that can be compared with the modification time for the files that compose that index and then decides to delete anyone that is older than the "expiration date".
since time_t is used for the stat.mtime there is a chance that the timestamp might overflow its size, so if an overflow is detected we assume the value to be equivalent to "never" and keep the files.
note this scenario will only matter around 2038 and it should be fixed by then as part of the Year 2038 problem if we still care about 32-bit UNIX by then, 32-bit Windows has until next century.
Carlo