tie() with DB_File not tie()ing ?

[Anno Siegel]

------------
irrelevant at this point... by copying a db file from the website that
is working, and running the same test program on it, with the same
local path, it was able to tie() without error and tell me the number
of records in the file. Pretty much sells me that the file I restored
from the host that melted down is 'slightly corrupted', or at least the
file descriptors are messed up somehow such that tie(0 cant figure the
file out even though it exists and is readable as far as the -f and -r
tests went.

so... the question now becomes whether anyone can hazard a guess how
a file can exist and be readable to -f and -r, but returns an error 'No
such file or directory' from tie() using DB_File.

The error in $! is probably misleading. It contains the last system
error the program encountered, but we don't know if the failed tie()
actually caused the error. It could come from anywhere.

Repairing a defect database can be tricky or impossible. I'd try to
get diagnostics directly from Berkeley DB. DB_File doesn't seem to
have debug options. There is also the more general module BerkeleyDB.
I don't know it, but I'd take a look there.

The Berkeley DB web site is http://www.sleepycat.com. There is also
a mailing list at (e-mail address removed).

Anno

 

[Lukas Mai]

they are way up out of sight in a config file that this particular
script pulls in via 'require'

No, they aren't. strict and warnings have lexical scope, i.e. they don't
affect anything outside their innermost containing block. A file is a
kind of block. A "require"d file can't enable strict/warnings for its
caller (outer code).

HTH, Lukas

 

[Charles DeRykus]

------------
irrelevant at this point... by copying a db file from the website that
is working, and running the same test program on it, with the same
local path, it was able to tie() without error and tell me the number
of records in the file. Pretty much sells me that the file I restored
from the host that melted down is 'slightly corrupted', or at least the
file descriptors are messed up somehow such that tie(0 cant figure the
file out even though it exists and is readable as far as the -f and -r
tests went.

so... the question now becomes whether anyone can hazard a guess how
a file can exist and be readable to -f and -r, but returns an error 'No
such file or directory' from tie() using DB_File.

followed by, can it be 'fixed?"

Can you confirm that the Berkeley libraries are the same... they're
installed by default in /usr/local/lib

/usr/local/lib/libdb-4.1.a
/usr/local/lib/libdb-4.1.so
...

Try a global file search though if you don't find them in /usr/local/lib.

Also, are the same versions of DB_File being used... you can check
by trying:

$ perl -M'DB_File 9999'
DB_File version 9999 required--this is only version 1.814.
BEGIN failed--compilation aborted.

I'm not sure this will reveal anything but there may be some
incompatiblity between versions...

 

[botfood]

Repairing a defect database can be tricky or impossible. I'd try to
get diagnostics directly from Berkeley DB. DB_File doesn't seem to
have debug options. There is also the more general module BerkeleyDB.
I don't know it, but I'd take a look there.

The Berkeley DB web site is http://www.sleepycat.com. There is also
a mailing list at (e-mail address removed).
--------------

thx, got it, read it, and will attempt to use it.... might be a real
trick running thru Shell to remote webserver host, but I'll give it a
shot. I have a short-term method to recover *most* of the data via a
flat textfile dump I did a couple weeks ago for a special report.

d