This is the mail archive of the
cygwin@sources.redhat.com
mailing list for the Cygwin project.
Re: CVS install
- To: "Fifer, Eric" <EFifer at sanwaint dot com>
- Subject: Re: CVS install
- From: "Charles S. Wilson" <cwilson at ece dot gatech dot edu>
- Date: Thu, 21 Sep 2000 11:36:16 -0400
- CC: cygwin at sources dot redhat dot com
- References: <779F20BCCE5AD31186A50008C75D99791717A9@silldn_mail1.sanwaint.com>
"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@sourceware.cygnus.com