RE: [Bug-tar] Skipped files with --listed-incremental after rename

[Alex Adriaanse]

Hi Joerg,

Thanks for your informative e-mail.

> If a filesystem does not update st_ctime, it breaks UNIX rules,
> since st_ctime
> indicates an inode change which I believe a rename(2) definitely is.

On the Linux kernel mailing list they pointed out that this is not true.  To
quote J.W. Schultz in his e-mail to me:
> rename(2) manpage:
>       Any other hard links to the file (as created using
>       link(2)) are unaffected.
>
> A change to ctime would affect the other links.
>
> stat(2) manpage:
>       The field st_ctime is changed by writing or by
>       setting inode information (i.e., owner, group, link
>       count, mode, etc.).
>
> I am not aware of any field in the inode structure that must
> be changed by an atomic rename.  Per documentation the only
> reason rename should update st_ctime is if it does a
> link+unlink sequence which would alter st_nlink briefly.
>
> On the other hand it does seem to me there ought to be some
> record that something about the inode changed.  st_ctime would
> be the only appropriate indicator.
>
> rename() SUSv3:
>       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.

Essentially, rename does NOT update the inode, so the ctime should not be
modified.  Only the directory entries pointing to that inode are changed.

Alex