[Aide] I (ignore changed filename) woes

[Bob Proulx]

Richard van den Berg wrote:
> Thanks Bob for the detailed description of your concerns.
> 
> Bob Proulx wrote:
> > So knowing that names of files are not stored in the inode but are
> > stored in the directory then we can see that renaming files in a
> > directory will not update the ctime of the file but it will update the
> > mtime of the directory.
>
> I just did a test (using GNU ls) on Linux on tmpfs:
> [...ctime updates on a linux kernel...]
> and on Solaris using GNU ls on tmpfs:
> [...ctime updates on a solaris kernel...]

Thanks for your refutation.  I learned something today on a topic that
I had thought that I understood fairly well.

> As you can see, the ctime is updated when the name of a file is changed.

I found this reference upon further search.  This is what the
standards say on this topic.

  http://www.opengroup.org/onlinepubs/009695399/functions/rename.html

  APPLICATION USAGE

    Some implementations mark for update the st_ctime field of renamed
    files and some do not.  Applications which make use of the st_ctime
    field may behave differently with respect to renamed files unless
    they are designed to allow for either behavior.

So the standard says it can go either way.  It is fine to update the
ctime, or not, and apparently some systems do and some don't.

I discussed this with a learned friend and this is what he had to say
about this behavior.

George Robbert wrote:
>     One of the fields in the inode is the link count (st_nlink).  So
> making a new hard link to the file will change the inode because it
> will increment st_nlink, and thus change st_ctime.  (Similarly
> removing a hard-link will decrement st_nlink and update st_ctime).
> ...
>     I believe this is goes back to rename(2) implementing (in a
> guaranteed atomic fashion) what the v7 mv command did with separate
> system calls.  I.e.
>
>       rename(a, b);
>
> replaced the old sequence
>
>       unlink(b);
>       link(a, b);
>       unlink(a);
>
> Which shows that st_nlink will be incremented and then decremented
> (both updating st_ctime).  Of course, since st_nlink ends up with the
> same value as before, that reason isn't so obvious.

That rationale makes sense.  Because if things were being linked and
unlinked then of course the ctime changes as st_link changes.  And
rename came later to replace that atomically and I could see it being
desirable to preserve the traditional behavior with regards to ctime.

Bob