root@libove.UUCP (Jay M. Libove) (10/08/88)
I use "find (files) | afio (etc...)" to backup my SCO Xenix 286 v2.2.1 filesystem, which is at around 80 megabytes right now. I would like to be able to do incremental backups, but I'm having a problem... My manual entry for find(C) (SCO uses bogus manual sections, that should be find(1) to the real world I think) says: find pathname-list expression ... -atime n True if the file has been accessed in n days. -ctime n True if the file has been changed in n days. -mtime n True if the file has been modified in n days. Okay, so "find -?time 3 -print" should find all files ?'d within the last three days, right? Nope. To wit: ================================================== [root]/usr/local/bin:(1 ) % ls -lt | head -10 -rwxr-xr-x 1 bin bin 111 Oct 8 09:10 lpq -rwxr-xr-x 1 root root 34513 Oct 7 09:57 pcomm_input -rwxr-xr-x 1 root root 180264 Oct 7 09:57 pcomm -rwxr-xr-x 1 root root 88865 Oct 7 02:32 vn -rwxr-xr-x 1 root root 12432 Oct 6 12:25 lesskey -rwxr-xr-x 1 root root 45329 Oct 6 12:25 less -rwxr-xr-x 1 bin bin 249 Oct 5 19:06 uulck -rwxr-xr-x 1 bin bin 89 Oct 5 08:18 ckuucp -rwxr-xr-x 1 bin bin 25775 Oct 4 19:19 psc [root]/usr/local/bin:(2 ) % find . -mtime 1 -print ./less ./vn ./lesskey ./pcomm ./pcomm_input [root]/usr/local/bin:(3 ) % find . -mtime 2 -print ./uulck ================================================== As you can see, -mtime 1 included only those files modified in the day preceeding, and -mtime 2 included only those files modified in the day preceeding the day preceeding, _not_ files modified within the last two days. This obviously makes it difficult to use % find . -mtime (epoch_days) | afio ... to back up the filesystem incrementally. So, is this the correct behaviour for find(1) (oops, pardon me SCO, find(C)) ? While I have your attention :-) Since, correct behaviour or not, this is what I have... does anyone have Thanks for any suggestions.a suggestion on how to work around this, in order to do reasonable incremental backups with commands like: (find appropriate files by date) | afio ... [ remark: afio is an enhanced cpio ] Thanks in advance! Jay Libove ARPA: jl42@andrew.cmu.edu or libove@cs.cmu.edu 5731 Centre Ave, Apt 3 BITnet: jl42@andrew or jl42@drycas Pittsburgh, PA 15206 UUCP: uunet!nfsun!libove!libove or (412) 362-8983 UUCP: psuvax1!pitt!darth!libove!libove -- Jay Libove ARPA: jl42@andrew.cmu.edu or libove@cs.cmu.edu 5731 Centre Ave, Apt 3 BITnet: jl42@andrew or jl42@drycas Pittsburgh, PA 15206 UUCP: uunet!nfsun!libove!libove or (412) 362-8983 UUCP: psuvax1!pitt!darth!libove!libove
morrell@hpsal2.HP.COM (Michael Morrell) (10/11/88)
> I use "find (files) | afio (etc...)" to backup my SCO Xenix 286 v2.2.1 > filesystem, which is at around 80 megabytes right now. I would like to > be able to do incremental backups, but I'm having a problem... > find pathname-list expression > ... > -atime n True if the file has been accessed in n days. > -ctime n True if the file has been changed in n days. > -mtime n True if the file has been modified in n days. > Okay, so "find -?time 3 -print" should find all files ?'d within the > last three days, right? Nope. ---------- You didn't read the man page carefully enough. Earlier in the page it says (or at least it does on my system): In the descriptions of the primaries, the argument n is used as a decimal integer where +n means more than n, -n means less than n and n means exactly n. This says that a "find -mtime -3 -print" will find all files modified within the last 3 days. Hope this helps, Michael
rar@nascom.UUCP (Alan Ramacher) (10/12/88)
To do incremental backups with find: 1) backup everything 2) create a file with the current time as creation date: e.g. touch epoch-day 3) when you wish to do an incremental backup issue the following: find directory(s) -newer epoch-day -whatever 4) reset time of incremental backup touch epoch-day I have been using this method for some time with good results. Hope this helps. If you have any further questions feel free to e-mail them. Allan Ramacher
merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) (10/12/88)
In article <170@libove.UUCP>, root@libove (Jay M. Libove) writes: | | My manual entry for find(C) (SCO uses bogus manual sections, that should | be find(1) to the real world I think) says: | | find pathname-list expression | ... | -atime n True if the file has been accessed in n days. | -ctime n True if the file has been changed in n days. | -mtime n True if the file has been modified in n days. | | Okay, so "find -?time 3 -print" should find all files ?'d within the | last three days, right? Nope. Right. Nope. As it says in TFM (Ultrix, but you can translate...)... "In the descriptions, the argument n is used as a decimal integer where +n means more than n, -n means less than n, and n means exactly n." Yup. Can you guess the correct response? Try: find <wherever> -?time -3 -print ^ +====== this was missing I know, 14 other people are typing in this reply at this very moment. Oh well. -- Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 on contract to BiiN Technical Information Services (for now :-), in a former Intel building in Hillsboro, Oregon, USA <merlyn@intelob.intel.com> or ...!tektronix!inteloa[!intelob]!merlyn Standard disclaimer: I *am* my employer!
jbm@uncle.UUCP (John B. Milton) (10/12/88)
In article <170@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes:
[ describes problem with find . -[acm]time n -print
Note that the sign of the number argument to the [acm]time switch should
have some kind of sign on it to work right:
find . -ctime 100 -print
find . -ctime +100 -print
find . -ctime -100 -print
all do different things
John
--
John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu
home (614) 294-4823, work (614) 764-4272; Send vi tricks, I'm making a manualtim@attdso.ATT.COM (Tim J Ihde) (10/13/88)
In article <170@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes: >My manual entry for find(C) (SCO uses bogus manual sections, that should >be find(1) to the real world I think) says: > >find pathname-list expression >... >-atime n True if the file has been accessed in n days. >-ctime n True if the file has been changed in n days. >-mtime n True if the file has been modified in n days. > >Okay, so "find -?time 3 -print" should find all files ?'d within the >last three days, right? Close. If you look at the first paragraph in the description section, you will see: "In the descriptions, the argument n is used as a decimal integer where +n means more than n, -n means less than n and n means exactly n." Therefore if you want all files ?'d within the last three days, you should use "find -?time -3 -print." It is also sometimes helpful to note exactly what atime, mtime, and ctime mean. These times are read using the stat(2) system call and are as defined on that man page, which shows which system calls change which time: atime creat(2), mknod(2), pipe(2), utime(2), read(2) mtime creat(2), mknod(2), pipe(2), utime(2), write(2) ctime chmod(2), chown(2), creat(2), link(2), mknod(2), pipe(2), unlink(2), utime(2), write(2) Also, be aware of which of these times ls is giving you. Normally, you see mtime; -u will give you atime and -c will give you ctime. Given that, let me say that I don't really like using the -?time options for incrementals. It would be too easy to miss something using units like "days" (I'm not positive what that means in this context: does -1 mean yesterday or 24 hours ago?) Rather, I usually do something like find . -newer old_flist -print | tee new_flist | cpio . . . This works pretty well, but be careful of files changed during the process; they might not get backed up today and skipped tomorrow. Usually I do this sort of thing from single user mode. -- Tim J Ihde UUCP: att!attdso!tim (201) 898-6687 INTERNET: tim@attdso.att.com "Blimey - this redistribution of wealth is more complicated than I'd thought!" - Dennis Moore and various Presidents
greywolf@unisoft.UUCP (The Grey Wolf) (10/13/88)
!In article <170@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes:
![ How he uses find for backups... ]
!Okay, so "find -?time 3 -print" should find all files ?'d within the
!last three days, right? Nope. To wit:
[ listing omitted ... explanation below ]
!==================================================
!As you can see, -mtime 1 included only those files modified in the day
!preceeding, and -mtime 2 included only those files modified in the day
!preceeding the day preceeding, _not_ files modified within the last two
!days. This obviously makes it difficult to use
!
!% find . -mtime (epoch_days) | afio ...
!
!to back up the filesystem incrementally.
For that you use:
% find . -mtime +(epoch_days) | afio ...
(the + means that it will look at anything older than epoch_days; a -
would indicate that it would be looking at things younger than epoch_days).
!
! ---
!
! Jay Libove ARPA: jl42@andrew.cmu.edu or libove@cs.cmu.edu
! 5731 Centre Ave, Apt 3 BITnet: jl42@andrew or jl42@drycas
! Pittsburgh, PA 15206 UUCP: uunet!nfsun!libove!libove or
! (412) 362-8983 UUCP: psuvax1!pitt!darth!libove!libove
! --
--
** All views expressed herein are my own and not those of UniSoft Corp. **
# Statement: Not Invented Here. My answer: See Figure 1. #
# Roan (RO-an) Anderson, UniSoft Corporation, (415) 420-6410 x 168. #
# ...sun!unisoft!greywolf # /harley/davidson: Mount device busy.###########
# ---- ENTROPY: SORRY, FOLKS, THAT'S THE WAY THE COSMOS CRUMBLES -----jay@phoenix.Princeton.EDU (Jay Plett) (10/13/88)
In article <3013@mipos3.intel.com>, merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) writes: > In article <170@libove.UUCP>, root@libove (Jay M. Libove) writes: > where +n means more than n, -n means less than n, and n means exactly > n." It's also worth knowing that integer division is involved. "find /fubar -?time +3" means "more days than 3", ie 4 days or more. 3 days 23 hours 59 minutes 59 seconds doesn't hit. My simple intuition would have guessed that 3 days + 1 second is "more than 3 days". jay@princeton.edu
snoopy@sopwith.UUCP (Snoopy T. Beagle) (10/13/88)
In article <170@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes: |My manual entry for find(C) (SCO uses bogus manual sections, that should |be find(1) to the real world I think) says: | |find pathname-list expression |... |-atime n True if the file has been accessed in n days. |-ctime n True if the file has been changed in n days. |-mtime n True if the file has been modified in n days. | |Okay, so "find -?time 3 -print" should find all files ?'d within the |last three days, right? Nope. To wit: No, probably not. "+n" means more than n, "-n" means less than n, and "n" means *exactly* n. (Unless SCO messed with the definition of n, which I doubt.) Also note the "-newer" option, if your find(C) [everyone else's find(1)] has it. This give you resolution down to the resolution of the mtime itself, (normally to the second) rather than to a day. The bad news is that you are stuck with mtime with -newer, it doesn't let you choose between all three. :-( _____ /_____\ Snoopy /_______\ |___| tektronix!tekecs!sopwith!snoopy |___| sun!nosun!illian!sopwith!snoopy
jr@oglvee.UUCP (Jim Rosenberg) (10/14/88)
In article <170@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes: >Okay, so "find -?time 3 -print" should find all files ?'d within the >last three days, right? Nope. To wit: Gimme an R, Gimme a T, Gimme an F ... You want e.g. find -mtime -3 -print ^ **/ \** This is pretty clearly documented, even though if you are using SCO no doubt your man page for find(1) has been bowderlized to eliminate the original (more or less): BUGS The syntax is painful. -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include <disclaimer.h>
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (10/18/88)
In article <170@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes: | My manual entry for find(C) (SCO uses bogus manual sections, that should | be find(1) to the real world I think) says: One of the things I like about Xenix is that I can explain to users that section C is commands, S systems calls, T text processing, etc. When V.4 and Xenix merge this is one thing I would really like to see change. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
prophet@nitro.ATT.COM (Mike Brooks) (10/18/88)
In article <12364@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <170@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes: > >| My manual entry for find(C) (SCO uses bogus manual sections, that should >| be find(1) to the real world I think) says: > > One of the things I like about Xenix is that I can explain to users >that section C is commands, S systems calls, T text processing, etc. >When V.4 and Xenix merge this is one thing I would really like to see >change. How about this then: #define C 1 /* for commands */ #define S 2 /* for system calls */ What would be better though is to break out things like text processing, especially since they are add-ons , as opposed to base level commands and system calls.... Michael
sar@datcon.UUCP (Simon A Reap) (10/19/88)
In article <1400@nitro.ATT.COM> prophet@nitro.UUCP (Mike Brooks) writes: >In article <12364@steinmetz.ge.com>davidsen@crdos1.UUCP(bill davidsen) writes: >>In article <170@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes: >>| My manual entry for find(C) (SCO uses bogus manual sections, that should >>| be find(1) to the real world I think) says: >> One of the things I like about Xenix is that I can explain to users >>that section C is commands, S systems calls, T text processing, etc. >What would be better though is to break out things like text >processing, especially since they are add-ons , as opposed to >base level commands and system calls.... (gross elision performed) Ah, but pity the poor user who doesn't *know* that text processing is an addon on their particular system, or the poor programmer who doesn't *know* that 'time' is a system call and 'ctime' a library routine. Life gets hard if you don't have on-line manuals :-(, but you do have the fun of being sidetracked by funky-looking calls as you flick through the pages :-) -- Enjoy, yerluvinunclesimon Opinions are mine - I don't even have a cat Reach me at sar@datcon.co.uk, or ...!mcvax!ukc!pyrltd!datcon!sar