home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!beartrk!ceilidh!hijo-2!dnichols
- From: dnichols@ceilidh.beartrack.com (Don Nichols (DoN.))
- Newsgroups: comp.sys.3b1
- Subject: Re: What's in Development Set?
- Keywords: warning backup UA
- Message-ID: <1992Jul28.013915.3762@ceilidh.beartrack.com>
- Date: 28 Jul 92 01:39:15 GMT
- References: <1992Jul22.124105.4309@brtph560.bnr.ca> <1992Jul23.150331.6182@mydual.uucp> <7526@public.BTR.COM>
- Organization: D and D Data, Vienna Virginia
- Lines: 38
-
- In article <7526@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes:
- >In article <1992Jul23.150331.6182@mydual.uucp> olson%mydual.uucp@alliant.com writes:
-
- [ ... ]
-
- >|FULL BACKUP ISN'T.
-
- [ ... ]
-
- >Heh, heh.
- >
- >The trick is altering the date AND contents of /etc/.installdate
- >
- >On my systems (for some time now):
- >
- > $ ls -l /etc/.installdate
- > -r--r--r-- 1 root root 29 Jan 1 1970 .installdate
- > $ cat /etc/.installdate
- > Thu Jan 1 00:00:00 PST 1970
- >
- >If you want to do the same (as root):
- >
- > echo "Thu Jan 1 00:00:00 PST 1970" > /etc/.installdate
- > touch -m 0101000070 /etc/.installdate
-
- Has anyone checked whether find(1) treats time as a signed or
- unsigned integer. (Someone posted a while back that the internal lib
- routine in 3.51 treat it as an unsigned integer, but what happens if find
- encounters a file given a date past the crucial time in 2038. Does it
- consider it as being *before* the begining of 1970 as some systems do, or
- does it consider it as being past 2038. Perhaps we should set the time to
- 0x80000000, and use that to ensure that *everything* gets backed up. :-)
-
- --
- Donald Nichols (DoN.) | Voice (Days): (703) 704-2280 (Eves): (703) 938-4564
- D&D Data | Email: <dnichols@ceilidh.beartrack.com>
- I said it - no one else | <dnichols@ceilidh.aes.com>
- --- Black Holes are where God is dividing by zero ---
-