On Monday 09 April 2007, Jon LaBadie wrote:
>On Sun, Apr 08, 2007 at 09:43:13PM -0500, dustin AT zmanda DOT com wrote:
>> On Sun, Apr 08, 2007 at 08:29:53PM -0500, Marc Mengel wrote:
>> > Couldn't someone hack up a utility to do a major number swapout in
>> > the file where tar keeps track of what is in the last
>> > incremental/full/etc.?
>>
>> That's what I suggested in
>>
>> http://tech.groups.yahoo.com/group/amanda-users/message/62562
>>
>> I'm a little busy to work on it at the moment, if you're interested in
>> taking up the task!
>>
>> Dustin
>
>Not a show stopper, but if someone does take up the task it will be
> important to consider various OS's and tar versions so as to avoid
> linux-specific type assumptions. As an example, here are two
> gnutar-lists from different OS's and "I think" different tar releases:
>
> 834 589377 ./jon/.gconf/desktop/gnome/accessibility
>
> 7602561 33040 ./jon/.gconf/apps/epiphany
>
>In each case the second column is the inode number. I'm guessing that
> the first column is somehow identifying the device, despite their
> wildly different format/sizes. It is the same for each entry in the
> file, though they could vary if "include's" in the DLE definition could
> pull in things from multiple file systems.
>
>If the current, new device value that tar will use is not known, it
> could be obtained with something like this:
>
> cd <head of DLE>
> mkdir -p _foo/foo
> tar -cf /dev/null --listed-incremental=_bar _foo
> awk 'NR=2 {print $1}' _bar
> rm -r _foo _bar
> cd -
>
>Assumes you can write to <head of DLE> and nothing there is named _foo
> nor _bar.
For linux at any rate this is derivable from a simple 'stat /' command.
root@coyote linux-2.6.21-rc6]# stat /
File: `/'
Size: 4096 Blocks: 16 IO Block: 4096 directory
Device: fe00h/65024d Inode: 2 Links: 29
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2007-04-09 11:09:13.000000000 -0400
Modify: 2007-04-08 14:11:57.000000000 -0400
Change: 2007-04-08 14:11:57.000000000 -0400
Subtract the 00h, and you have the 254 its currently sitting at,
apparently subject to the whims of an individual boot. If I build md as
a module, then md will get 254 and device-mapper (dm_mod) will get 253,
and if I build pktcdvd, the packet writing util for burning cd/dvd's, it
will get one of those numbers, shoving device-mapper down to 252. This
number does not change AFAIK, for any file/directory on that particular
disk. To demo:
root@coyote linux-2.6.21-rc6]#
stat /usr/local/etc/amanda/Daily/amanda.conf
File: `/usr/local/etc/amanda/Daily/amanda.conf'
Size: 22454 Blocks: 48 IO Block: 4096 regular file
Device: fe00h/65024d Inode: 11534709 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 501/ amanda) Gid: ( 6/ disk)
Access: 2007-04-09 11:35:51.000000000 -0400
Modify: 2007-04-09 10:09:02.000000000 -0400
Change: 2007-04-09 10:09:02.000000000 -0400
The Device: number is the same.
Question then: Does tar use the expanded hex value given first, or the
decimal version, which isn't quite a 1/1 translation according to mental
hex calculator. Humm, wet ram must need refreshed, kcalc says it does.
And an inspection of the revelant files says its the decimal version,
present as the first number of every line in the file AFTER line 1. So
this is doable by a bash script I believe. But I'll need a nap and 3
more cups before I start that project.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"I don't know, " said the voice on the PA, "apathetic
bloody planet, I've no sympathy at all. "
|
