lwv@n8emr.UUCP (Larry W. Virden) (04/03/89)
I am using find on both Ultrix 2.3 and SunOS 4.0.1 on a 386i. I have a file whose ls -l date (documented as the modification time) is April 1, 1989 at 9:09 am. On my machine, it is after 10am on April 3. I run find filename -mtime +1 -print. My file's name does not appear. I run find filename -mtime 1 -print. My file's name DOES appear. Note that it is more than 48 hours after the modification time. Why does find insist that the mtime is only 1 day old? -- Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (INTERNET) The world's not inherited from our parents, but borrowed from our children.
bink@aplcen.apl.jhu.edu (Ubben Greg) (04/04/89)
In article <976@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: > >I am using find on both Ultrix 2.3 and SunOS 4.0.1 on a 386i. I have >a file whose ls -l date (documented as the modification time) is >April 1, 1989 at 9:09 am. On my machine, it is after 10am on April 3. >I run find filename -mtime +1 -print. My file's name does not appear. >I run find filename -mtime 1 -print. My file's name DOES appear. > >Note that it is more than 48 hours after the modification time. Why does >find insist that the mtime is only 1 day old? I'm posting this response to Larry's question, as it may be of general interest. Experimentation with the FIND and TOUCH commands reveals that the argument forms -N, N, and +N, are always mutually exclusive (as math's <, =, and > operators are). The form N refers to the 24-hour period ENDING exactly N days ago, +N refers to any time before that period, and -N refers to any time after that period. For example, the primaries "-mtime 0" and "-mtime -1" are both true only on files that have been modified within the last 24 hours. "-mtime 1" is true for files that are between 48 and 24 hours old, and "-mtime +1" is true for files that haven't been modified within the last 48 hours. The extra day can be accounted for by the time change that occured on April 2nd. It WASN'T more than 48 hours after the modification time yet -- it just appears that way because the "before" time is formatted in standard time and the "after" time is formatted in daylight savings time. -- Greg Ubben bink@aplcen.apl.jhu.edu
pinkas@hobbit.intel.com (Israel Pinkas ~) (04/05/89)
In article <976@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: > I am using find on both Ultrix 2.3 and SunOS 4.0.1 on a 386i. I have > a file whose ls -l date (documented as the modification time) is > April 1, 1989 at 9:09 am. On my machine, it is after 10am on April 3. > I run find filename -mtime +1 -print. My file's name does not appear. > I run find filename -mtime 1 -print. My file's name DOES appear. > > Note that it is more than 48 hours after the modification time. Why does > find insist that the mtime is only 1 day old? Actually, in most of the United States, we lost an hour between 2 and 3 am on April 2. Therefore, from 9:09 am, April 1 to 10:00 am, April 3, there was only 47:51 elapsed time. I don't know whether this is a bug or not. My understanding is that "-mtime 1" means that the file was modified 1 day ago. I assume that this means between one and two days. "-mtime +1" means more than one day. To me this means at least two days. Thus, if the modification date were 9:09, April 1, I would expect: -mtime means ------ ----- 1 10:09 April 2 through 10:08 April 3 +1 10:09 April 3 and later -1 before 10:09, April 2 * One could argue that the time should be 9:09. That is, the clock time matters, not the elapsed time. -Israel Pinkas -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas ARPA: pinkas%cadev4.intel.com@relay.cs.net CSNET: pinkas@cadev4.intel.com
bill@bilver.UUCP (bill vermillion) (04/06/89)
In article <976@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: > >I am using find on both Ultrix 2.3 and SunOS 4.0.1 on a 386i. I have >a file whose ls -l date (documented as the modification time) is >April 1, 1989 at 9:09 am. On my machine, it is after 10am on April 3. >I run find filename -mtime +1 -print. My file's name does not appear. >I run find filename -mtime 1 -print. My file's name DOES appear. > >Note that it is more than 48 hours after the modification time. Why does >find insist that the mtime is only 1 day old? > It's relatively simple - from the way I see it. Your file is less than 48 hours old. All files times are stored in GMT - (or UCT now). From 909am April 1, that should be 1409 GMT. 10am on April 3 should be 1400 GMT. GMT did NOT change at 2am Sunday, but your computer went from EST to EDT. Thus 10am Monday is only 47 hours and 50 minutes later than 910AM saturday. Just a stroke of timing. If you had waited another 10 or 15 minutes you probably wouldn't have seen it. -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!bill : bill@bilver.UUCP
SIMSN%NUSDISCS.BITNET@cunyvm.cuny.edu (12/12/89)
Can anyone explain what's the difference between atime, mtime, ctime? I'm not sure how to interpret "accessed", "modified" and "changed". Seems to me like it all meant when the file was "touched". Thanks. > Sim Ser Ngarn (Jnet%"SIMSN@NUSDISCS") > National University of Singapore > Department of Information Systems and Computer Science
tyson@csusac.csus.edu (Gary Tyson) (12/12/89)
In article <21721@adm.BRL.MIL> SIMSN%NUSDISCS.BITNET@cunyvm.cuny.edu writes: > > > Can anyone explain what's the difference between atime, mtime, > ctime? > > I'm not sure how to interpret "accessed", "modified" and > "changed". Seems to me like it all meant when the file was > "touched". You are correct in thinking "a" is access etc. But... When you "touch" a file you make it appear to have been modified. Access time is changed when a file is read or modified (true if touched) Modify time is changed when a file is modified (but read alone isnt enough) Change time is changed when a file's inode is modified (this is also true if a file is modified) You might try the manual entry for stat for more info. (Or man -k time) Hope this helps. Gary Tyson P.S. I am still looking for a book on a.out and ld... Help!
drears@pica.army.mil (Dennis G. Rears (FSAC)) (12/13/89)
Sim: You write: > > Can anyone explain what's the difference between atime, mtime, > ctime? > atime - The last time the file was read or modified. The system calls creat(2), mknod(2), utimes(2), read(2), and write(2) will affect the atime value. mtime - The last time the contents of the file was modified. The systems calls creat(2), mknod(2), utimes(2), and write(2) affect the mtime value. Open(2) will if called with the O_WRONLY flag. ctime - The last time information about the file was changed or the file was written to. This is affected by systems calls like chmod(2), chown(2), creat(2) link(2), mknod(2), unlink(2), utimes(2), and write(2). If the file is a directory atime is not modified when the directory is searched. On some occasions atime will not be modified when the file is written to. (Zample: ULTRIK -> echo " ">>filename). Read the manual page for stat. That explains it pretty well. Dennis
chris@mimsy.umd.edu (Chris Torek) (12/13/89)
In article <1989Dec12.060748.29698@csusac.csus.edu> tyson@csusac.csus.edu (Gary Tyson) writes: >Access time is changed when a file is read or modified (true if touched) >Modify time is changed when a file is modified (but read alone isnt enough) >Change time is changed when a file's inode is modified (this is also true > if a file is modified) This is mostly correct, except that the access time is not changed if the file is written, only if it is read. `ctime' can be thought of as `time of last operation that requires that the file be backed up'. A backup program can decide whether a file needs saving by comparing the file's ctime with the time of the previous backup. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
chris@mimsy.umd.edu (Chris Torek) (12/13/89)
In article <21727@adm.BRL.MIL> drears@pica.army.mil (Dennis G. Rears (FSAC)) writes: >atime - The last time the file was read or modified. The system >calls creat(2), mknod(2), utimes(2), read(2), and write(2) will affect the >atime value. Some editions of stat(2) make this claim. They are wrong. (The man page is fixed in 4.4BSD, and might be fixed in 4.3 and/or 4.3-tahoe.) Namely, read(2) should be deleted to correct the list. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (12/13/89)
In article <21231@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: | `ctime' can be thought of as `time of last operation that requires that | the file be backed up'. A backup program can decide whether a file needs | saving by comparing the file's ctime with the time of the previous backup. No. ctime is the time of a change to the *inode* not the file. A smart backup program can just save the new inode info and restore that, if incremental dumps are being done. As an example, if you change the access with chmod, the inode time will change, and ctime will be updated. Since the content of the file has not changed the actual file itself doesn't need to be backed up. The only backup which appears to take advantage of this is "dump," and I'm not sure that the feature is in all versions. It is important to understand the distinction, however, between changing the contents and the characteristics. The field which indicates that the file content has been changed is the modified time (find param -mtime). -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
les@chinet.chi.il.us (Leslie Mikesell) (12/13/89)
In article <21231@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >`ctime' can be thought of as `time of last operation that requires that >the file be backed up'. A backup program can decide whether a file needs >saving by comparing the file's ctime with the time of the previous backup. Unless, of course, someone has run cpio with the -a option for the previous backup like the SysV sysadmin scripts do. The -a option resets the atime in order to pretend that the file has not been read, and in the process modifies ctime. Also, wouldn't it make sense for "find -newer" to compare ctime instead of mtime (except in the above circumstance)? Les Mikesell les@chinet.chi.il.us
chris@mimsy.umd.edu (Chris Torek) (12/14/89)
>In article <21231@mimsy.umd.edu> I wrote: >>`ctime' can be thought of as `time of last operation that requires that >>the file be backed up'. A backup program can decide whether a file needs >>saving by comparing the file's ctime with the time of the previous backup. In article <1917@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > No. ctime is the time of a change to the *inode* not the file. I stand by my statement. Your second sentence is correct if you change the last three words to `or contents of the file'. (Note that the inode *is* the file, in some sense, so `inode, not file' is self-contradictory.) >A smart backup program can just save the new inode info and restore that, >if incremental dumps are being done. As an example, if you change the >access with chmod, the inode time will change, and ctime will be >updated. Since the content of the file has not changed the actual file >itself doesn't need to be backed up. > > The only backup which appears to take advantage of this is "dump," and >I'm not sure that the feature is in all versions. Although this works for this example, this is not what the 4BSD dump/restore do, and in particular, it is not reliable. Consider, e.g., the following: 0. file system backup done on 12/13/1989 1. inode 12345 removed 2. inode 12345 allocated by `tar' from archive made 12/1/1989: timestamps are atime=12/1/1989, mtime=12/1/1989, ctime=12/14/1989 Now we run the backup program. If it saves only the inode contents, and not the file contents as well, it will assume that (since inode 12345 was on the dump made on 12/13, and its mtime is 12/1) the contents are good and it needs only the permissions, times, etc. If we subsequently restore the file, we will find that it has the permissions of the file created by tar, but the contents of the file that was removed in step 1 above. >It is important to understand the distinction, however, between changing >the contents and the characteristics. The field which indicates that the >file content has been changed is the modified time (find param -mtime). Almost, but not quite, because of utimes(2). The mtime can, at any time, be changed to either `now' or any arbitrary value. If you examine the kernel source, you will see that whenever the mtime is changed, the ctime is also changed to `now'. In other words, modifying the file's contents updates the file's ctime. (dump is a bit paranoid, checking both the mtime and ctime when doing backups. This is unnecessary, and in fact will back up too many files if utimes() is used to set the mtime into the future.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
chris@mimsy.umd.edu (Chris Torek) (12/14/89)
>>atime - The last time the file was read or modified. The system >>calls creat(2), mknod(2), utimes(2), read(2), and write(2) will affect the >>atime value. In article <21260@mimsy.umd.edu> I wrote: >... read(2) should be deleted to correct the list. Oops! That should be `write(2) should be deleted'---naturally read() updates the atime. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
decot@hpisod2.HP.COM (Dave Decot) (12/14/89)
> In article <21727@adm.BRL.MIL> drears@pica.army.mil > (Dennis G. Rears (FSAC)) writes: > >atime - The last time the file was read or modified. The system > >calls creat(2), mknod(2), utimes(2), read(2), and write(2) will affect the > >atime value. > > Some editions of stat(2) make this claim. They are wrong. (The man > page is fixed in 4.4BSD, and might be fixed in 4.3 and/or 4.3-tahoe.) > Namely, read(2) should be deleted to correct the list. But it's not complete. For instance, the system call open() affects atime. Note also that POSIX.1-1988 requires (on page 112 of the softcover book) the read() function to mark the st_atime field for update. Dave
les@chinet.chi.il.us (Leslie Mikesell) (12/14/89)
In article <1917@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > No. ctime is the time of a change to the *inode* not the file. A smart >backup program can just save the new inode info and restore that, if >incremental dumps are being done. As an example, if you change the >access with chmod, the inode time will change, and ctime will be >updated. Since the content of the file has not changed the actual file >itself doesn't need to be backed up. If the ctime has changed, you don't have any way to tell how much else has changed, and thus the proper thing to do is to copy the current state. For example: files foo.1 and foo.2 exist make your full backup mv foo.2 foo.1 make your incremental based on mtime + the inode info If you restore this, foo.1 is not going to contain what it did at the time the incremental was taken. Likewise if you copy files in with cpio -m or anything else that can maintain the mtime. > The only backup which appears to take advantage of this is "dump," and >I'm not sure that the feature is in all versions. It is important to >understand the distinction, however, between changing the contents and >the characteristics. The field which indicates that the file content has >been changed is the modified time (find param -mtime). Perhaps if the incremental is based on inodes instead of directories it would notice these changes, but "find -mtime" won't. Les Mikesell les@chinet.chi.il.us
musson@usdtsg.Dayton.NCR.COM (Scott Musson) (01/11/90)
Can someone tell me how to get rid of the following problem? when I do a 'find p* -mtime +1 -print' in a directory with a large number of files starting with 'p', I get find: too many arguments. I can subdivide the list with smaller segments of the files I want to find, but I would like another way around this if possible. Can anyone point me in the right direction? Thnaks, Scott Musson NCR San antonio
jik@athena.mit.edu (Jonathan I. Kamens) (01/11/90)
In article <388@usdtsg.Dayton.NCR.COM>, musson@usdtsg.Dayton.NCR.COM (Scott Musson) writes: > when I do a 'find p* -mtime +1 -print' in a directory with a large number of > files starting with 'p', I get find: too many arguments. > > I can subdivide the list with smaller segments of the files I want to find, > but I would like another way around this if possible. Can anyone point me > in the right direction? There is no way around it. The shell has a built-in limit on the number of arguments that can be parsed on the command line. Furthermore, there is a kernel limit on the number of arguments passed into any particular program execution. You'll have to do your finding by breaking it up into smaller sets of files. I cannot resist pointing out that any directory that has so many files into it that they can't be passed into find probably has too many files in it and should be reorganized :-). Seriously, if the directory in question has no subdirectories, (or if you want it to search the subdirectories too), you could do "find . -name p\* -mtime +1 -print", which solves the problem. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
cpcahil@virtech.uucp (Conor P. Cahill) (01/11/90)
In article <388@usdtsg.Dayton.NCR.COM>, musson@usdtsg.Dayton.NCR.COM (Scott Musson) writes: > > when I do a 'find p* -mtime +1 -print' in a directory with a large number of > files starting with 'p', I get find: too many arguments. The problem is not with find, but with the shell (and OS). There is a maximum number of arguments and/or number of bytes in those arguments. Usually this number is on the order of 5120 bytes. To get around your problem you could do the following: Create the following shell: pgm="$1" shift args="" while [ ! -z "x$1" ] do if [ "x$1" = "xendargs" ]; then shift; break; else args="$args $1" shift fi done $pgm $* $args and call it manysh. now you can do: ls | grep "^p" | xargs | manysh find -mtime +1 -print -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
gwyn@smoke.BRL.MIL (Doug Gwyn) (01/13/90)
In article <388@usdtsg.Dayton.NCR.COM> musson@usdtsg.UUCP (Scott Musson) writes: >Can someone tell me how to get rid of the following problem? >when I do a 'find p* -mtime +1 -print' in a directory with a large number of >files starting with 'p', I get find: too many arguments. The following (not tested) should work: find . -mtime +1 -print | sed 's/^\.\///' | grep '^p'
danj1@cbnewse.ATT.COM (Dan Jacobson) (01/15/90)
cpcahil@virtech.uucp (Conor P. Cahill) errs, so I just have to point out:
> while [ ! -z "x$1" ]
but on the test(1) man page:
-z s1 true if the length of string s1 is zero.
So the "while" will always be "! false" == "true".
--
Dan Jacobson +1-708-979-6364 danj1@ihlpa.ATT.COM