Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<3F065A28.7050902@cwilson.fastmail.fm>
Date:	Sat, 05 Jul 2003 00:55:04 -0400
From:	Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language:	en-us, en
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Problem with perl dbmopen command
References:	<Pine DOT BSF DOT 4 DOT 50 DOT 0307041843540 DOT 67449-100000 AT ampere DOT fing DOT edu DOT uy>
In-Reply-To:	<Pine.BSF.4.50.0307041843540.67449-100000@ampere.fing.edu.uy>

Andres Azar wrote:
> Hello.
> 
> I'm running cygwin 1.3.22 under Windows ME.
> Following commands
> 
>   $ 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
> /tmp/htagd79287565.pag
> 
> Dbmopen seems to have failed. It is sure to generate *.dir file besides
> *.pag file.
> 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 
files).

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.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -