Re: [PATCH] Make use of stat.ctime configurable

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 29, 2008, 02:49 UTC
Message-ID: <7vy73lmmk6.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080729014120.GA26807@old.davidb.org>

David Brown <git@davidb.org> writes:

Show 13 quoted lines

> On Mon, Jul 28, 2008 at 06:31:24PM -0700, Junio C Hamano wrote:
>>Linus Torvalds <torvalds@linux-foundation.org> writes:
>>
>>> The kernel does caching really well, and the kernel is fast as
>>> hell, so _of_course_ when you benchmark, using kernel data
>>> structures looks good, especially if you benchmark against code
>>> that isn't well written for the particular usage case.
>>
>>Ok.  While I have your attention on st_ctime, let me ask you a stupid
>>question.  Why does "rename(old, new)" change st_ctime when you move a
>>regular file?
>
> A simple answer might be that posix requires it.

I would understand that an obvious implementation would be to link to new and then unlink the old, and the link count of the moved entity needs to change (although in the end, the increment and decrement would cancel out) in each step, so it would be convenient for the implementation to update ctime in both steps; however my reading of POSIX does not seem to require it.

The only mention of ctime I find is about updating the parent directories of old and new, as contents of both change so do their mtime and ctime obviously need to change. But it does not talk about ctime of the entity being moved.

Additionally, the only way rename(2) is described to fail with EMLINK is when renaming an directory and the parent of the new location cannot have any more links; which implies that it does not have to fail if the first step of link+unlink overflows the link count of old.

Ah, I found in the informative Application Usage section that this is implementation dependent.

Sorry for the noise.