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

David Brown [off-list ref] writes:

On Mon, Jul 28, 2008 at 06:31:24PM -0700, Junio C Hamano wrote:

quoted

Linus Torvalds [off-list ref] writes:

quoted

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.