updating @cb and @ub

Fairlight fairlite at fairlite.com
Fri Dec 22 10:57:40 PST 2006


In the relative spacial/temporal region of
Fri, Dec 22, 2006 at 11:38:22AM -0500, Kenneth Brody achieved the spontaneous
generation of the following:
> Quoting VL (Fri, 22 Dec 2006 08:49:59 -0600):
> [...]
> > What is the format of the key and data files?  How would I go about
> > updating them with perl?  No indexes on @cb or @ub.
> 
> http://www.fptech.com/Support/fpplustp.shtml

Which omits some very important data.  Namely, how are you storing the uid
and the date over multiple bytes?  I've tried both LSB and MSB, and neither
comes out to the right solution on the uid.

Example:  I have (in less) <E7>^C for my uid bytes.  Converted, that's \347
and \003 in octal (which was the easiest representation for /bin/echo to
print out, and the fastest to work with in perl because you can just quote
escape it.

Converted, the closest I got was 823.  The actual uid is 999.

How are these stored?  A little 2-3 line C snippet would be beneficial, as
I'm mathematically challenged.  :)

# Here's what I tried...
sub give_uid {
     my ($uid,$one,$two);
     ($one,$two)=split(//,$_[0]);
     $one = unpack('C',${two})<<8;
     $two = unpack('C',${one});
     $uid= ${one} + ${two};
     return(${uid});
}

That was the one that came closest.  If I reversed byte-order as far as
which was bit-shifted, it was far larger a number and wayyyyy off.

That said, given the actual byte storage conversion details, it's a fairly
simple matter to write something that analyses the map for the total record
length, rewrites the bytes at the correct offsets in the headers while
copying the 20-byte header over, and copies the length of the user data
over after each header, repeat to EOF.  Not a problem.

Not something I'd do for free, but not a problem in overall.  It's just a
lot of reading and writing preset amounts of bytes, and inbetween the two
you do substitutions where necessary.  Not hard to do--IF you have the
storage algorithm for the bytes representing the data.

It would be handy to understand how they're stored and where I'm going
wrong on this, not necessarily for this specific instance, but in general
if I ever have to muck about with the headers.  FWIW, bit-shifting and
byte-representation storage was always a bit dodgy for me, which is why I
can't seem to pin it down on my own just yet.  I could keep hammering at
it, but why not ask?

mark->
-- 
Try our new SPF-0 lotion, SunScream[tm].  Get it while it's hot!


More information about the Filepro-list mailing list