This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: CVS install

"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_*.


Want to unsubscribe from this list?
Send a message to

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]