vlcek@athena.mit.edu (Jim C Vlcek) (09/23/90)
I'm running AIX PS/2 v1.1 on a Model 80, and noticed a rather disturbing thing: file(1) changes the "change" time on files if the user is the owner of those files. To wit: % ls foo.c % stat foo.c Filename: foo.c Size in bytes: 91 Size in Blocks: 0 File-Type: Regular File mode:(0600) -rw------- Owned By User: vlcek (200), Group: staff (1) dev = 2 inode = 227 links = 1 Access: Fri Sep 21 00:03:26 1990 Modify: Fri Sep 21 00:03:15 1990 Change: Fri Sep 21 00:03:15 1990 % date ; file foo.c Sat Sep 22 17:58:06 EDT 1990 foo.c: c program text % stat foo.c Filename: foo.c Size in bytes: 91 Size in Blocks: 0 File-Type: Regular File mode:(0600) -rw------- Owned By User: vlcek (200), Group: staff (1) dev = 2 inode = 227 links = 1 Access: Fri Sep 21 00:03:26 1990 Modify: Fri Sep 21 00:03:15 1990 Change: Sat Sep 22 17:58:06 1990 I'm sure this is not the intended behavior (it doesn't do it on the 4.3BSD systems I work on). Someone please tell me this is fixed in v1.2? Also, I've noticed that file chokes on sockets, returning a "cannot open for reading" error. Come on, guys, if it's a socket, it's identified as such right in the mode bits, you don't _need_ to open it for reading! Jim Vlcek (vlcek@caf.mit.edu vlcek@athena.mit.edu)
richard@locus.com (Richard M. Mathews) (09/24/90)
vlcek@athena.mit.edu (Jim C Vlcek) writes: >I'm running AIX PS/2 v1.1 on a Model 80, and noticed a rather >disturbing thing: file(1) changes the "change" time on files if the >user is the owner of those files. >I'm sure this is not the intended behavior (it doesn't do it on the >4.3BSD systems I work on). Someone please tell me this is fixed in v1.2? This is a feature inherited from System V. It appears that it was decided that access time was more important to preserve than change time. The code uses utime() to set the access time back to its original value after the file has been read. This has not been changed in 1.2. Richard M. Mathews Locus Computing Corporation richard@locus.com lcc!richard@seas.ucla.edu ...!{uunet|ucla-se|turnkey}!lcc!richard
guy@auspex.auspex.com (Guy Harris) (09/24/90)
>I'm sure A dangerous phrase indeed.... >this is not the intended behavior (it doesn't do it on the >4.3BSD systems I work on). It is a consequence of the behavior AT&T intended the "file" command to have. The System V "file" resets the time of last access on the file after reading it, using the "utime()" call; this has the effect of changing the inode change time. The V7 "find" didn't do that, and Berkeley didn't add that behavior in 4.xBSD. Whether it should do this is another matter; I don't care one way or the other, but other people do - dunno how many people want the change time to stay the same and the access time to change, and how many people want the access time to be reset and the change time to change.
vlcek@athena.mit.edu (Jim C Vlcek) (09/25/90)
Guy Harris points out that file(1) changing the change time of a file is a SysV-ism, and not a problem in AIX. (Somehow, when I wrote "I'm sure this is not the intended behavior", I was sure that something like this would happen...) The notion that "file" should modify the access time makes perfect sense to me; the notion that updating the access time should cause the change time automatically to be updated does not. This betrays my own prejudice that one must access a file first in order to modify or change it - in this state of affairs, the access time and change time would be synonymous. I know I'm betraying my ignorance here, but I'll ask anyway: what do people find the "change" time useful for? I always key on the access time (generally to find "dead" files that no one uses any more that can be deleted) and the modify time (usually to sniff out files that have been updated since a distribution was installed). I don't know if I've ever looked at the change time. Jim Vlcek (vlcek@caf.mit.edu vlcek@athena.mit.edu)
richard@locus.com (Richard M. Mathews) (09/25/90)
vlcek@athena.mit.edu (Jim C Vlcek) writes: >I know I'm betraying my ignorance here, but I'll ask anyway: what do >people find the "change" time useful for? I always key on the access >time (generally to find "dead" files that no one uses any more that >can be deleted) and the modify time (usually to sniff out files that >have been updated since a distribution was installed). I don't know >if I've ever looked at the change time. The default cleanup of /tmp done by /usr/adm/daily in AIX 1.2 uses find .... -atime +2 -ctime +2 The theory is that at least one of access-time or change-time will be updated when anything interesting happens to a file. When a file is read in using "backup" or "cpio", the mod-time and access-time might be set back, but the change-time will reflect the time it was put there. Any modification of the file will also set the change-time. Richard M. Mathews Freedom for Lithuania Locus Computing Corporation Laisve! richard@locus.com lcc!richard@seas.ucla.edu ...!{uunet|ucla-se|turnkey}!lcc!richard
guy@auspex.auspex.com (Guy Harris) (09/26/90)
>The notion that "file" should modify the access time makes perfect >sense to me; the notion that updating the access time should cause the >change time automatically to be updated does not. This betrays my own >prejudice that one must access a file first in order to modify or >change it - in this state of affairs, the access time and change time >would be synonymous. "Change" in the phrase "change time" in UNIX has a fairly specific meaning; it refers to a change to the contents of the inode (or its moral equivalent on UNIX file systems, if any, that don't have inodes), with the exception of a change to the access time caused by actually reading the file. "Access" also has a fairly specific meaning; it refers to reading the data of a file. So you don't have to "access" a file in order to "change" it - doing a "chmod()" call on the file will "change" it (i.e., modify its inode) but not "access" it (i.e., not read any data from it). >I know I'm betraying my ignorance here, but I'll ask anyway: what do >people find the "change" time useful for? It's used by dump programs, so that they'll dump a file (or, at least, its inode) even if the *contents* of the file haven't changed, if the permissions or owner or... have changed. Presumably, the reason why the change time is updated if some program explicitly sets the access time (as the S5 "file" does), is so that the change to the access time gets recorded on the next dump. The reason why it's not updated when the access time is updated when the file is read is that dumps would take a *lot* more space if it were....
jim@segue.segue.com (Jim Balter) (09/26/90)
In article <1990Sep24.190145.20519@athena.mit.edu> vlcek@athena.mit.edu (Jim C Vlcek) writes: >I know I'm betraying my ignorance here, but I'll ask anyway: what do >people find the "change" time useful for? Backup programs want to know if the inode changed so that they can back up changes in such things as file ownership, modes, and mod or access times. In case it isn't clear to anyone, mtime is affected by changes in the data of the file, ctime is affected by changes in the file's inode (including a change to atime or mtime).