Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!ucsfcgl!pixar!rta From: rta@pixar.UUCP (Rick Ace) Newsgroups: comp.unix.wizards Subject: Re: 4.3BSD rename() changes ctime Summary: rename changes ctime to alert /etc/dump the file has changed Keywords: ctime dump rename Message-ID: <2167@pixar.UUCP> Date: 5 Aug 88 14:41:46 GMT References: <26657@oliveb.olivetti.com> Organization: Pixar -- Marin County, California Lines: 33 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! It doesn't seem right > that a system call that doesn't change the inode or the data in the file > should result in the file being dumped in the next backup. > > Is this a bug or is there some justification for rename updating the > ctime? The principal purpose of the ctime field in the I-node is to alert /etc/dump that the file has changed in *some way* and must be backed up. In the case of "rename", the file's name has changed; thus the file has changed in some way, and that fact must be recorded by /etc/dump. When performing a non-level-0 dump, /etc/dump uses the ctime field in its decision to determine whether or not to select a file for backup. If anything about a file changes (mode, nlinks, data contents, name, etc.), then that must be noted on a dump tape. Unfortunately, /etc/dump operates on an "all or nothing" basis, so in this case you pay the price of backing up both the I-node's contents and the file's data just to record the fact that the name alone changed. (Indeed, there is not enough information in the I-node for /etc/dump to distinguish between cases where the file's data has changed and when only an I-node field has.) Rick Ace Pixar 3240 Kerner Blvd San Rafael CA 94901 ...!{sun,ucbvax}!pixar!rta