brisco@caip.rutgers.edu (Thomas Paul Brisco) (07/01/87)
To test a program I'm trying to build a lot of files with
varying creation dates -- trouble is; I can't seem to find any
references to it. I've looked over our Pyramid 9810 and Sun 3's with
no luck. I'd like to try and do this in a fairly portable way (so
that it will work on suns and pyramids) - and will try most anything
short of bringing the machine down single user and setting the date (;-).
I've checked all through the ioctl.h and fcntl.h as well as
file.h and haven't seen anything that pointed me in the right
direction. Does anyone have any idea how to go about this?
Thanks;
Tp.
--
----------------------------------------------------------
- ARPA: Brisco@rutgers -
- UUCP: (ihnp4!ut-sally, allegra!packard) !caip!brisco -
----------------------------------------------------------chris@mimsy.UUCP (Chris Torek) (07/01/87)
In article <4280@caip.rutgers.edu> brisco@caip.rutgers.edu (Thomas Paul Brisco) writes: >To test a program I'm trying to build a lot of files with >varying creation dates -- trouble is; I can't seem to find any >references to it. Unix files (V6, V7, 2BSD, 3BSD, 4BSD, Sys3, Sys5 release any) do not carry creation dates, only access (atime), modify (mtime), and inode-change (ctime) dates. Ctime is often erroneously called the file creation time. Its real purpose is for backups. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
ark@alice.UUCP (07/01/87)
In article <7273@mimsy.UUCP>, chris@mimsy.UUCP writes: > Unix files (V6, V7, 2BSD, 3BSD, 4BSD, Sys3, Sys5 release any) do > not carry creation dates, only access (atime), modify (mtime), and > inode-change (ctime) dates. Ctime is often erroneously called > the file creation time. Its real purpose is for backups. It is often called the file creation time because it once was the file creation time. Its meaning changed sometime before V7. Old habits die hard.
mpl@sfsup.UUCP (07/01/87)
In article <4280@caip.rutgers.edu>, brisco@caip.rutgers.edu.UUCP writes: > To test a program I'm trying to build a lot of files with > varying creation dates -- trouble is; I can't seem to find any UNIX(R) does not keep a creation time! Do you mean the "ctime" field of the stat struct? That is the modification time of the i-node (change time). This is updated by chmod, write, or just about anything you do. You *can't* explicitly set this, as far as I know.
hasch@siemens.UUCP (Harald Schaefer) (07/01/87)
You can set the access and modification time by using a system call utime(2). The modification time is probaply the creation time you're lookling for. Harald.
mikep@ism780c.UUCP (Michael A. Petonic) (07/01/87)
In article <4280@caip.rutgers.edu> brisco@caip.rutgers.edu (Thomas Paul Brisco) writes: > To test a program I'm trying to build a lot of files with >varying creation dates -- trouble is; I can't seem to find any >references to it. > I've checked all through the ioctl.h and fcntl.h as well as >file.h and haven't seen anything that pointed me in the right >direction. Does anyone have any idea how to go about this? First of all, you have to realize that what is show when you do an "ls -lc <file>" is not the creating date. UNIX doesn't even store that despite what the user-level documentation says. It stores the last time that the i-node for the file was modified or created. Now, since the i-node contains info about the number of links, you could change the c-time of a file, merely by making a link to it and then removing the new link. This will give the original file the new c-time of whatever time it is. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The company and all my associates and friends and ESPECIALLY the government put me up to say all this useless trash. MikeP {seismo|sdcrdcf}!ism780c!mikep "Some of my best friends are Bigots..."
kimcm@olamb.UUCP (Kim Chr. Madsen) (07/03/87)
In article <1582@sfsup.UUCP>, mpl@sfsup.UUCP writes: > > UNIX(R) does not keep a creation time! Do you mean the "ctime" field of > the stat struct? That is the modification time of the i-node (change > time). This is updated by chmod, write, or just about anything you do. > You *can't* explicitly set this, as far as I know. Some UNIX systems does however provide touch(1) with the option of setting a specified timestamp, and for the appropiate time entries in the inode information (atime, mtime and ctime). If your UNIX systems doesn't support this feature the solution is to write the utility which can be done quite simple (supposing you have access to root priviledges) by following the following sceme: read date and time set UNIX time touch the file (in a way so only the wanted times are affected) reset the UNIX time Kim Chr. Madsen
jfh@killer.UUCP (07/08/87)
I have posted my version of the Version 7 settime(1) command to comp.sources.misc. Watch for it! - John.
mpl@sfsup.UUCP (M.P.Lindner) (07/17/87)
In article <1108@killer.UUCP>, jfh@killer.UUCP writes: > > I have posted my version of the Version 7 settime(1) command to > comp.sources.misc. Watch for it! > > - John. :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) I just read it! Seriously, have you ever heard of "touch"? Read section 1 of your UNIX(R) manual! :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{)
pdg@ihdev.ATT.COM (Joe Isuzu) (07/20/87)
In article <1650@sfsup.UUCP> mpl@sfsup.UUCP (M.P.Lindner) writes: >In article <1108@killer.UUCP>, jfh@killer.UUCP writes: >> I have posted my version of the Version 7 settime(1) command to >> comp.sources.misc. Watch for it! >I just read it! >Seriously, have you ever heard of "touch"? Read section 1 of your UNIX(R) >manual! OK. SYNOPSIS touch -c -f file Hmmm. I'm not sure how that would let me set the time of a file to anything I want. (That was BSD 4.2). Just remember, system V is not the only UNIX version out there - indeed on SysV, you can use touch for setting file times, and I'm sure John was quite aware of that. He mentioned Version 7, and from the looks of the manual, the Berkeley touch has not changed from the V7 touch. -- Paul Guthrie "Another day, another Jaguar" ihnp4!ihdev!pdg -- Pat Sajak
jfh@killer.UUCP (The Beach Bum) (07/23/87)
In article <1650@sfsup.UUCP>, mpl@sfsup.UUCP (M.P.Lindner) writes: > In article <1108@killer.UUCP>, jfh@killer.UUCP writes: > > > > I have posted my version of the Version 7 settime(1) command to > > comp.sources.misc. Watch for it! > > > > - John. > > :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) > I just read it! > Seriously, have you ever heard of "touch"? Read section 1 of your UNIX(R) > manual! > :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) :{) I must remember not to post replies to some of these articles. There is always some joker that doesn't know how to think his way out of a paper bag and posts an assinine follow-up like this one. Usually has something to do with a one-system view of the world. Something like 'my system has this version of tooch, therefore they all do'. Not all touch(1)'s are created equally!!! And yes, I have heard of touch. I also know of the cases in which touch cannot be used. 1). read-only devices. opens for writting would be disallowed and touch would fail. 2). zero length files. some old versions of touch actually read the first byte, rewound the file and wrote the first byte right back. 3). magnetic tape drives. opening for writing and then closing will cause an eot mark to be written very close to the beginning of the tape. 4). serial devices. you can imagine the results here. 5). directories. we all know you can't open a directory for writing. In fact, the only place I could think of touch working was files that were Regular Files, and had a non-zero length. FIFO's, which didn't exist in Version 7 don't count, but then I can't vouch for Berkeley Unix and what manner of wierdness it has for files, or how it's touch works this semester. Oh, and one last little jab while in the area. Can touch make two files have the same atime and mtime down to the last second without having to set them _both_ to a certain time? No, of course not. I didn't think so. - John. --- -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993