This is the mail archive of the
mailing list for the Cygwin project.
Re: Problem with perl dbmopen command
Andres Azar wrote:
I'm running cygwin 1.3.22 under Windows ME.
$ perl -e 'dbmopen(%A,"/tmp/htagd79287565",0600) && print"OK\n"'
$ ls -l /tmp/htag*
yield this result:
-rw-r--r-- 1 andres all 3072 Jun 20 12:57
Dbmopen seems to have failed. It is sure to generate *.dir file besides
Running perl version: 5.8.0-3.
did perl *report* a failure? If not, then it thinks that it succeeded
-- and it is right.
See, perl's database backend is actually handled by libgdbm. And gdbm
*emulates* dbm functionality: it names the database foo.pag -- but the
file actually contains a gdbm-format database (and gdbm uses only a
single file, not two files).
Now, to make "real" dbm implementations interoperate, gdbm helpfully
creates a HARDlink 'foo.dir' to foo.pag (since "real" dbms expect both
However, hardlinks will fail on FAT drives -- normally, cygwin will fall
back to creating a copy instead of a hardlink, if hardlinks are not
permitted on the filesystem. Perhaps THAT behavior has changed.
I recommend the following tests:
#1) try your same command on an NTFS filesystem
#2) try 'ln /tmp/htagd79287565.pag /tmp/htagd79287565.pag' on your
current /tmp (which I believe is FAT) and see what happens -- a copy, a
"transparent" failure, what?
Note that even if cygwin falls back to creating foo.dir as a COPY of
foo.pag, that is BAD. It kinda works, but dbm REQUIRES that both the
.pag and .dir file have EXACTLY the same timestamp. This is really only
possible in the gdbm if the two files are hardlinks -- if one is a copy
of the other, then the timestamps WILL get out of sync, because gdbm
will only ever update the ONE file that it actually needs.
Short answer: don't use gdbm in dbm-emulation mode (or perl dbm*
commands) on a FAT drive.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html