Path: utzoo!utgpu!attcan!uunet!nbires!ncar!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: 4.3BSD rename() changes ctime
Keywords: ctime dump rename
Message-ID: <12822@mimsy.UUCP>
Date: 4 Aug 88 07:12:26 GMT
References: <26657@oliveb.olivetti.com>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 23

In article <26657@oliveb.olivetti.com> jerry@olivey.olivetti.com
(Jerry Aguirre) writes:
>Prior to the "rename" system call the mv command would change the ctime
>of a file even though the resulting data AND inode were identical.  This
>was an anavoidable consequence of the link and unlink process used to
>implement renaming.

>Well, now that we have rename, it still does! ...

>Is this a bug or is there some justification for rename updating the
>ctime?

There is certainly *some* justification: in fact, rename works
internally by adjusting the link count temporarily, so that if the
machine crashes, at least one of the two names will exist (but both
might exist).  If it were to do otherwise, fsck would not be able
to fix things.  One could argue that it should then go back and
reset the ctime after the rename completes, although there is no
kernel mechanism to do this (iupdat() insists on using the current
time: ip->i_ctime = time.tv_sec).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris