duane@anasaz.UUCP (Duane Morse) (06/01/89)
The "file" command on our NCR Tower 32/600 (version 1.04.02) and on
our Motorola 8650 changes the creation time of the files it examines.
The file command doesn't do that on some of our other Unix systems
(Microport 286, Interactive 386). Is there any reason (other than
brain damage) why "file" should change the creation time?
--
Duane Morse ...{asuvax or mcdphx}!anasaz!duane
(602) 861-7609guy@auspex.auspex.com (Guy Harris) (06/03/89)
>The "file" command on our NCR Tower 32/600 (version 1.04.02) and on >our Motorola 8650 changes the creation time of the files it examines. If what you say is completely true, you must be running a pretty bizarre version of UNIX; no version I know of maintains the *creation* time of a file. Now, most versions I know of maintain the time the inode was last changed; this is often called the "ctime", and people often make a huge and bogus leap and assume that the "c" stands for "creation". So, we'll assume you're running a fairly ordinary version of UNIX, and that you meant "(inode) change time" rather than "creation time".... >The file command doesn't do that on some of our other Unix systems >(Microport 286, Interactive 386). Is there any reason (other than >brain damage) why "file" should change the creation time? "file" generally has to read a file to figure out what type of file it is. Normally, this would cause the access time of the file to be updated. The S5 version of "file" dutifully tries to pretend that it *didn't* read the file, and does a "utime" call to reset the access time to its pre-read value. This causes the inode change time to be modified, to flag the fact that, well, the inode was changed by the "utime" call. This call only works if you're super-user or own the file. The reason why it doesn't happen on your Microport or Interactive system is probably one of: 1) they took the "reset-the-access-time" hack out of "file"; 2) you didn't own the file on the other systems, but did own it on the Tower; 3) you didn't do it as super-user on the other systems, but did on the Tower; 4) "file" is set-UID "root" on the Tower; 5) other. I don't know that there's a compelling reason why "file" should reset the access time, other than "well, it does that as shipped by AT&T, and we don't want to change it"; whether this is "compelling" or not depends on how important vanillitude of your UNIX is to you.
hill@faline.bellcore.com (Chris Hill) (06/08/89)
In article <> guy@auspex.auspex.com (Guy Harris) writes: >If what you say is completely true, you must be running a pretty bizarre >version of UNIX; no version I know of maintains the *creation* time of a >file. If so, to what "creation" time does the -c option of ls refer? Chris Hill chris@nyquist.bellcore.com
dune@cbnewsl.ATT.COM (Greg Pasquariello) (06/13/89)
In article <2268@faline.bellcore.com> hill@faline.UUCP (Chris Hill) writes: >In article <> guy@auspex.auspex.com (Guy Harris) writes: >>If what you say is completely true, you must be running a pretty bizarre >>version of UNIX; no version I know of maintains the *creation* time of a >>file. > >If so, to what "creation" time does the -c option of ls refer? > >Chris Hill The "creation" time refers to the last modified time. If the last time the file was modified was at creation, well then it really is the creation time. However, if the file was modified since creation, the two times will not be the same. The inode doesn't even save the creation time, so it is not available. (Regardless of what the header says, I am Greg Pasquariello at ...!att!picuxa!gpasq)
rogerk@mips.COM (Roger B.A. Klorese) (06/14/89)
In article <2268@faline.bellcore.com> hill@faline.UUCP (Chris Hill) writes: >In article <> guy@auspex.auspex.com (Guy Harris) writes: >>If what you say is completely true, you must be running a pretty bizarre >>version of UNIX; no version I know of maintains the *creation* time of a >>file. > >If so, to what "creation" time does the -c option of ls refer? No "creation" time at all, but a "change" time, that of the inode when the permissions, ownership, etc. are changed. -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 928 E. Arques Ave. Sunnyvale, CA 94086 voicemail: +1 408 991-7802 {ames,decwrl,pyramid}!mips!rogerk rogerk@servitude.mips.COM "I want to live where it's always Saturday." -- Guadalcanal Diary
chris@mimsy.UUCP (Chris Torek) (06/14/89)
>In article <?> guy@auspex.auspex.com (Guy Harris) writes: >>... of UNIX; no version I know of maintains the *creation* time of a >>file. In article <2268@faline.bellcore.com> hill@faline.bellcore.com (Chris Hill) writes: >If so, to what "creation" time does the -c option of ls refer? One existing only in the mind of whoever wrote the manual entry. The manual entry has been fixed in time for the next BSD release (whenever that may be). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
hjg@amms4.UUCP (Harry Gross) (06/28/89)
In article <795@cbnewsl.ATT.COM> dune@cbnewsl.ATT.COM (Greg Pasquariello) writes: >In article <2268@faline.bellcore.com> hill@faline.UUCP (Chris Hill) writes: >>In article <> guy@auspex.auspex.com (Guy Harris) writes: >>>If what you say is completely true, you must be running a pretty bizarre >>>version of UNIX; no version I know of maintains the *creation* time of a >>>file. >> >>If so, to what "creation" time does the -c option of ls refer? ^^^^^^^^ It doesn't refer to creation time of any kind. >The "creation" time refers to the last modified time. If the last time the >file was modified was at creation, well then it really is the creation time. >However, if the file was modified since creation, the two times will not be >the same. The inode doesn't even save the creation time, so it is not >available. Actually, to quote from section 1 of the manual entry for 'ls' (you remember the manuals, don't you :-) :-) : -c Use time of last modification of the inode (mode, etc.) instead of last modification of the file for sorting (-t) and/or printing (-l) Also, the structure definition of an inode (as described in S5R2 manuals, section 4): ... time_t di_atime; /* time last accessed */ time_t di_mtime; /* time last modified */ time_t di_ctime; /* time of last status change */ ... I don't see any mention of the word 'creation' in any of the above entries :-) -- Harry | reserved for | something really Internet: hjg@amms4.UUCP (we're working on registering)| clever - any UUCP: {jyacc, qtny, rna, bklyncis}!amms4!hjg | suggestions?
guy@auspex.auspex.com (Guy Harris) (06/29/89)
>>If what you say is completely true, you must be running a pretty bizarre >>version of UNIX; no version I know of maintains the *creation* time of a >>file. > >If so, to what "creation" time does the -c option of ls refer? It doesn't refer to *ANY* "creation" time, it refers to the inode change time. If your manual says it refers to the creation time, either your manual is wrong or you're running a pretty bizarre version of UNIX.
guy@auspex.auspex.com (Guy Harris) (06/29/89)
>The "creation" time refers to the last modified time. If the last time the >file was modified was at creation, well then it really is the creation time. >However, if the file was modified since creation, the two times will not be >the same. The inode doesn't even save the creation time, so it is not >available. Almost correct. "ctime" isn't the last modified time, that's the "mtime", which is the time the file was last modified (i.e., written to, or truncated, or extended - i.e., any time the file size or the file contents were changed). "ctime" is the time the inode was last changed, which includes modifications of the sort "mtime" reports *and* modifications such as changing the owner of the file, or permissions of the file, or number of links to the file.
terryl@tekcrl.LABS.TEK.COM (06/30/89)
In article <1850@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > > >>If what you say is completely true, you must be running a pretty bizarre > >>version of UNIX; no version I know of maintains the *creation* time of a > >>file. > > > >If so, to what "creation" time does the -c option of ls refer? > >It doesn't refer to *ANY* "creation" time, it refers to the inode change >time. If your manual says it refers to the creation time, either your >manual is wrong or you're running a pretty bizarre version of UNIX. Well, then, Guy, I guess you can call 4.3 BSD+NFS "a pretty bizarre version of UNIX"; to wit, I quote part of the standard ls(1) man page: -c Use time of file creation for sorting or printing. Help Stamp Out Fascist News Software !!!! !!!!
frank@zen.co.uk (Frank Wales) (07/03/89)
In article <4217@tekcrl.LABS.TEK.COM> terryl@tekcrl.LABS.TEK.COM writes: >In article <1850@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >> >If so, to what "creation" time does the -c option of ls refer? >> >>It doesn't refer to *ANY* "creation" time, it refers to the inode change >>time. If your manual says it refers to the creation time, either your >>manual is wrong or you're running a pretty bizarre version of UNIX. > > Well, then, Guy, I guess you can call 4.3 BSD+NFS "a pretty bizarre >version of UNIX"; to wit, I quote part of the standard ls(1) man page: > > -c Use time of file creation for sorting or printing. In article <22874@iuvax.cs.indiana.edu> (Steve Hayman) writes: >Subject: Frequently Asked Questions about Unix - with Answers. > >11) How do I find out the creation time of a file? > > You can't - it isn't stored anywhere. Files have a last-modified > time (shown by "ls -l"), a last-accessed time (shown by "ls -lu") > and an inode change time (shown by "ls -lc"). The latter is often > referred to as the "creation time" - even in some man pages - but > that's wrong; it's the time the file's status was last changed, > either by writing or changing the inode (via mv or chmod, etc...). > > The man page for "stat(2)" discusses this. -- Frank Wales, Systems Manager, [frank@zen.co.uk<->mcvax!zen.co.uk!frank] Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217
guy@auspex.auspex.com (Guy Harris) (07/06/89)
>>It doesn't refer to *ANY* "creation" time, it refers to the inode change >>time. If your manual says it refers to the creation time, either your >>manual is wrong or you're running a pretty bizarre version of UNIX. > > Well, then, Guy, I guess you can call 4.3 BSD+NFS "a pretty bizarre >version of UNIX"; to wit, I quote part of the standard ls(1) man page: > > -c Use time of file creation for sorting or printing. Uhh, please note that I said that "either your manual is wrong or you're running a pretty bizarre version of UNIX"; the 4.3 BSD manual is simply wrong - it's *NOT* the bloody creation time, period, end of discussion - so unless as part of folding in NFS the folders added a creation time (*and* screwed up "ls" to have the "-c" flag print the creation time), their manual is wrong as well.
les@chinet.chi.il.us (Leslie Mikesell) (07/06/89)
> >>It doesn't refer to *ANY* "creation" time, it refers to the inode change > >>time. If anyone has mentioned this I must have missed it. This discussion started about find(1) changing the atime of files to pretend it didn't read them, thus unavoidably changing the ctime. The real problem with this is that if you do incremental backups based on ctime (which you should if you do incremental backups), anything that file(1) looked at is going to be copied unnecessarily. The same goes for the -a flag of cpio. Perhaps we need a real "archived" flag in the inodes since ctime is hopelessly overloaded and mtime (rightly) doesn't change when a file is renamed. Les Mikesell