CVS install

Wed Sep 20 09:32:00 GMT 2000

"Sagar R. Shah" wrote:
> 
> I've been havaing the exact same problems as Jeff.
> 
> I have installed gdbm
> I completely killed my cvs directory (rm -fr cvs;    mkdir cvs)
> 
> The version of cvs that i'm running is:
> Concurrent Versions System (CVS) 1.10.8 (client/server)
> 
> which I think is the latest version (of course I could be completely wrong)

you're not wrong -- that is the latest version in the cygwin distro.

> 
> I've attached my cygcheck 

CYGWIN is set incorrectly.  It should not be set to the "path to
cygwin1.dll" as you have done.  It should be something like:  "CYGWIN =
tty binmode ntsec"

I do not know if this could be causing the problem or not.  Also, I
notice that you are running on Win9x.  I've never tested cvs/gdbm (or
cygwin for that matter) on Win9X, since all I've got is WinNT and Win2K.

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.  

> and a bzipped version of my strace output (I'm not
> sure whether people would appreciate a 300K attachment)

Well, it seems that the .#1011 (or .#1053 or whatever) files are named
according to the PID of the cvs process. That's why the number keeps
changing.  However, I have NO idea why cvs is trying to create a
database with the name .#my-pid -- because it's also creating
.#my-pid.pag and .#my-pid.dir.  I can't even find any reference to pid
in the source...(not true, I understand the .#pid stuff now...it's just
a temporary name; gets renamed later...)

Below I've pasted the snippet from the strace output, which seems to be
where the error is occuring. cvs has already created .#1011 and
.#1011.pag.  Now, it's trying to create a symlink .#1011.dir ->
.#1011.pag  and hits a LOCK_VIOLATION error, and then does a bunch of
write_console calls (presumably to print out error messages and exit).

Waitaminute.  AHA! the link command is trying to create a hardlink
(Here's the ls -il output in *my* CVSROOT directory, on an NTFS
partition:

 560421 -rw-rw-rw-   2 cwilson  Users        3072 Dec  4  1999
modules.dir
 560421 -rw-rw-rw-   2 cwilson  Users        3072 Dec  4  1999
modules.pag

Obviously, that will fail on a FAT partition.  This must be happening
within the gdbm code.  Now, how to fix? (skip down to bottom of message)

  529 1727138 [main] CVS 1011 symlink_info::check: GetFileAttributesA
(C:\devel\cygwin\cvs\CVSROOT\.#1011.dir) failed
  298 1727436 [main] CVS 1011
/cygnus/netrel/src/cygwin-1.1.4/winsup/cygwin/path.cc:2264 seterrno: 2
(FILE_NOT_FOUND) -> 2
  254 1727690 [main] CVS 1011 symlink_info::check: 0 = symlink.check
(C:\devel\cygwin\cvs\CVSROOT\.#1011.dir, 0x268D055) (0x8)
  417 1728107 [main] CVS 1011 symlink_info::check: not a symlink
  294 1728401 [main] CVS 1011 symlink_info::check: 0 = symlink.check
(C:\devel\cygwin\cvs\CVSROOT, 0x268D055) (0x0)
  375 1728776 [main] CVS 1011 path_conv::check:
GetVolumeInformation(C:\) = OK,
full_path(C:\devel\cygwin\cvs\CVSROOT\.#1011.dir), set_has_a
cls(0)
 1741 1730517 [main] CVS 1011
/cygnus/netrel/src/cygwin-1.1.4/winsup/cygwin/syscalls.cc:615 seterrno:
33 (LOCK_VIOLATION) -> 13
  375 1730892 [main] CVS 1011 _link: -1 = link (.#1011.pag, .#1011.dir)
 3364 1734256 [main] CVS 1011 _fcntl: 0 = fcntl (5, 8, 0)
  252 1734508 [main] CVS 1011 _close: close (5)
 1518 1736026 [main] CVS 1011 fhandler_base::close: handle 0x94
 2213 1738239 [main] CVS 1011 _close: 0 = close (5)
 2692 1740931 [main] CVS 1011 _write: write (2, 0x268FD60, 3)
  260 1741191 [main] CVS 1011 fhandler_console::write: 268FD60, 3
  243 1741434 [main] CVS 1011 fhandler_console::write: at 99(c) state is
1
 5555 1746989 [main] CVS 1011 fhandler_console::write: 3 = write_console
(,..3)

--------------------

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").  

Perhaps a symlink will work instead?  I dunno. the reason the files are
linked is so that the timestamp on the .pag and .dir files are the
same.  I guess we need to fix it so that every time *.pag is written to,
you stat it, get its timestamp, and touch *.dir to set it's timestamp to
be the same.

Well, I just tried a 'cvs init' with CVSROOT=some_dir_on_a_FAT_drive
(but under WINNT) and it worked fine -- both with and without 'ntea' in
the CYGWIN variable.

On my WinNT test, strace cvs init has the following two lines:
 4197 7043381 [main] cvs 1444 _link: cannot write linkname, Win32 error
1
53654 7097035 [main] cvs 1444 _link: 0 = link (.#1444.pag, .#1444.dir)

the "cannot write linkname, Win32 error 1" message is missing in Sagar's
strace from a Win9x system.  Does the link(hardlink) command fail
gracefully on FAT partitions under WinNT, but die a horrible death on a
Win9x system?

Comments, anyone?  

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com