Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <39CA2AF0.B33FA497@ece.gatech.edu>
Date: Thu, 21 Sep 2000 11:36:16 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fifer, Eric" <EFifer AT sanwaint DOT com>
CC: cygwin AT sources DOT redhat DOT com
Subject: Re: CVS install
References: <779F20BCCE5AD31186A50008C75D99791717A9 AT silldn_mail1 DOT sanwaint DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Fifer, Eric" wrote:
> 
> Charles S. Wilson wrote:
> >It is possible that under Win9x, cvs/gdbm needs 'ntea' set in the CYGWIN
> >variable to work correctly.  However, the drawbacks to that are the
> >creation of *huge*, un-deletable files called "sf data.ea" in the root
> >of every FAT or FAT32 drive on your system.
> 
> ntea does nothing on Win9x, its is only meaningful on WinNT,
> ntea = Windows NT, Extended Attributes.

Oh yeah.  Where's my brown paper bag....

> 
> >Does the link(hardlink) command fail
> >gracefully on FAT partitions under WinNT, but die a horrible death on a
> >Win9x system?
> 
> It doesn't fail at all, it makes a copy of the file and reports success.

It seems to be failing w/o making a copy in Sagar's strace...

> 
> >Okay, the typically way to recover from the failure of hardlink creation
> >is to just do a copy.  However, we need to insure that *.pag and *.dir
> >are always in sync, since they are the backend files for a dbm-style
> >database (see dbminit.c in the gdbm source, which specifically states
> >that "file.dir will be linked to file.pag").
> 
> I don't know the specifics of this, but based on testing with Perl,
> gdbm by itself works fine.  However, with the dbm/ndbm emulation
> everything fails on FAT (Win9x and WinNT) because of the file copy.

I was afraid of that.  Thanks, Eric.

Okay, so you can't use cygwin-cvs to maintain a local repository on FAT
drives ==> you can't use cygwin-cvs to maintain a local repository on
Win9X systems.

However, if someone wants to send me a patch so that cvs uses gdbm calls
instead of ndbm calls, and #includes gdbm.h instead of ndbm.h, I'll
definitely consider it.  Pointer: the easiest way is probably to make
use of the myndbm feature that already exists in cvs; just replace the
function definitions in myndbm.c with wrappers to gdbm_* calls.  Should
be pretty straightforward, but watch for memory leaks on dynamically
allocated return structures: see <gdbm-src>/dbmseq.c and
<gdbm-src>/dbmfetch.c for examples...

(Also edit options.h so that MY_NDBM is defined)

I'd prefer that cvs use libgdbm for database access, over just using the
myndbm routines as they are currently coded in <cvs-src>/src/myndbm.c. 
That's why I suggest modifying the myndbm.c functions to become wrappers
for gdbm_*.

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com