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

Linus Torvalds [off-list ref] 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?

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

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.  But, from the point of
view of backup software, not updating the ctime on rename would be
horrible, because you'd never know when files got renamed.

David

On Mon, 28 Jul 2008, Junio C Hamano wrote:

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?

Hmm. I think that's just a plain POSIX oddity. There's no real "reason" 
for it, except the historical one: in really old UNIX terms, rename used 
to be a "link+unlink".

And that "link+unlink" updated ctime because the 'nlink' part of the inode 
changed. Never mind that it got changed right back ;)

			Linus

On Mon, 28 Jul 2008, Linus Torvalds wrote:

Hmm. I think that's just a plain POSIX oddity. There's no real "reason" 
for it, except the historical one: in really old UNIX terms, rename used 
to be a "link+unlink".

Side note: a lot of the mtime/ctime/atime rules are really pretty 
arbitrary. They've grown over time, and have various historic reasons.
'ctime' in particular is more arbitrary than most, and I don't at all 
guarantee that all Unixes will work exactly the same wrt ctime and rename. 

In fact, I -can- guarantee that some older versions of Linux haven't 
always updated ctime on renames, for example, and it's probably still 
per-filesystem.

			Linus

Hi,

On Mon, 28 Jul 2008, David Brown wrote:

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

quoted

Why does "rename(old, new)" change st_ctime when you move a regular 
file?

But, from the point of view of backup software, not updating the ctime 
on rename would be horrible, because you'd never know when files got 
renamed.

Any backup software that does not discover that there is a new _filename_ 
is not worth the label "software".  Rather "daftware" or somesuch.

Ciao,
Dscho