On Monday 09 April 2007, dustin AT zmanda DOT com wrote:
>On Mon, Apr 09, 2007 at 12:05:01PM -0400, Gene Heskett wrote:
>> 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:
>
>Is it the case, then, that any block device loaded as a module will get
>a dynamically generated major device number?  Or just devices which
>don't have a fixed major yet?
>
This is Logical Volume Manager stuffs.  I don't believe it effects 
partitions normally mounted from /etc/fstab, but I could be wrong.

>> Device: fe00h/65024d    Inode: 11534709    Links: 1
>>
>> 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.
>
>Could you send me a copy of your incremental file?  AFAICT, they're
>binary files, so I'm not sure how you're speaking of "lines"..

I don't think you are looking at the right file family then. Here, I find 
a file that points at a directory with no subdirs at all, apparently has 
only a unix style timestamp in a single line similar to the top line of 
this snip from /usr/local/var/amanda/gnutar-lists:
[amanda@coyote gnutar-lists]$ cat coyote_var_0
1175582239
60928 19300353 ./cache/gstreamer-0.8
60928 19169380 ./run/cups
60928 19169448 ./lib/scrollkeeper/az
60928 19595604 ./tmp/RealPlayer/share/locale/ko
60928 19300370 ./cache/yum/updates-source
60928 19235048 ./tmp/kdecache-root/background
60928 19169358 ./cache/man/local

However there is in this particular file one anomaly,
60928 19170711 ./lib/pgsql/data/base
18 9355 ./lib/nfs/rpc_pipefs <---
60928 19169412 ./lib/scrollkeeper/am

Which is actually a directory with other files in it according to an 
ls -l.  So that's a puzzle, and probably best if not kicked to see if its 
alive :)

Now a cat of the _5 version of that looks like this:
[amanda@coyote gnutar-lists]$ cat coyote_var_5
1175495769
60928 19169380 ./run/cups
60928 19300353 ./cache/gstreamer-0.8
60928 19169448 ./lib/scrollkeeper/az
60928 19595604 ./tmp/RealPlayer/share/locale/ko
60928 19300370 ./cache/yum/updates-source
60928 19169358 ./cache/man/local

And I've NDI why the top two entries are swapped.  Another of those 
sleeping dogs I suspect :)

And these are the files given to tar as reference files according to the 
runtar.$date.debug files I have.
 
>If there's private info in there, please use tar to make a new
>incremental of a non-private directory, rather than munging the file.
>
>Dustin

The above should give you an idea, nothing precious there that I know 
of. :)

FWIW, those 60928 numbers are the correct ones for a LANANA assigned #238, 
hex 1238=EEh & EE00h=60928

Now I just need a utility that will fix these that don't have that number 
there and I should be good to go.   Hint...

-- 
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)
Electromagnetic energy loss