On Sunday 21 December 2003 01:50, Jon LaBadie wrote:
>On Sun, Dec 21, 2003 at 12:00:42AM -0500, Gene Heskett wrote:
>> On Saturday 20 December 2003 18:44, Jon LaBadie wrote:
>> >On Sat, Dec 20, 2003 at 04:15:20AM -0500, Gene Heskett wrote:
>> >> IMO, if mods to amanda were required, maybe its time to take a
>> >> long hard look at George Schilling's 'star'. Among other
>> >> things star can, if the controlling tty sends it a ^\, it will
>> >> spit back out to the
>>
>> From my perspective, one of the attractive things about star is
>> only
>>
>> >nice for Solaris. It can reset the access time WITHOUT resetting
>> >the change time for the inode. So all 3 time stamps can be left
>> > unchanged.
>>
>> Well, I can say that that may or may not be an advantage Jon.
>> How, if tar doesn't set a timestamp someplace, does it otherwise
>> know that it did a full backup on this file yesterday, and only
>> needs to do an incremental today? Tar has no mechanism to dirctr
>> it to check its older logs that I know of.
>>
>> I've not figured it out, but the question isn't rhetorical either.
>
>No, here is the problem.
>
>1) If tar reads a file to back it up the access time (atime) is
> changed This does not happen with dump as it reads the disk file,
> not the individual files. Thus after a tar backup, every file
> looks like it was read. Obviously it was; by the backup program.
> But I would prefer the atime to show when was the last time some
> user accessed the file. Then I could say, heck this file hasn't
> even been read in the last 10 years, maybe it could be deleted :))
> But in this case it is a backup program, not a user changing the
> atime.
>
>2) So tar introduced the "restore atime" option, analogous to a
> "touch -a". However this also changes the "inode change time
> (ctime)". That is intended to be used when something like chown,
> chmod, touch, ... changes a property of a file without necessarily
> changing the data in the file. But again, it is a backup program,
> not a user changing the ctime. And it is really bad to change the
> ctime without a valid reason (I don't feel backup of a file a valid
> reason) because backup programs base their decision to backup a
> file by either the modification time (mtime) OR the ctime. So the
> file is incrementally backed up if either the data or the
> properties of the file are altered.
>
>As to your concern where the data of a file's backup is kept, it is
> not kept with each file. The date of the backup is kept by dump in
> /etc/dumpdates and by amanda-tar in /etc/amandates.
Wouldn't this be a decent excuse to get a new file time paramter
defined in all the usual filesystems? One that the backup program
can set in the inode, and restore the atime to original at the same
time? It seems to me that a decent proposal for such an item might
not be turned down forthwith by all parties concerned. In fact, I'm
a bit surprised it hasn't been proposed before, or did I miss all the
hand waving?
>So the problem is how to get tar to backup up things without
> changing ANY of the three time stamps. Star, on Solaris, can do
> it.**
>
>> How's the snow up in Jersey? We have about 7" on the ground here.
>
>We're clear at the moment. Well small patches. But the big storm
> gave us over a foot. Officially the weather guru's said 11 inches.
> But the 2x6 top of my deck railing, 8 - 15 ft from the house and
> 13 - 16 ft above ground, had a uniform depth of 13 inches of snow.
> I can see how it would show less snow than fell as wind could blow
> it away. But I don't see how it could have accumulated "more" snow
> than fell. Certainly nothing was drifting onto that 2x6 in
> mid-air.
>
>
>Happy Holidays!
You too, Jon & Gundy.
>
>jon
>
>
>** Star is fudging it a bit by using a Solaris system call that was
> introduced about 10 yrs ago for the express purpose of some
> software package that does not exist any longer. The system call
> was never formally documented as a part of the Solaris system, just
> as an addition for that software and was specifically listed as
> having the potential of disappearing in the future.
My manpage for star says that its possible that none of the file times
would be modified if certain options are all set. However, doesn't
that lead to needing a file named "stardate"?
Yeah, I know, very poor pun.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
|
