From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles S. Wilson" To: "Sagar R. Shah" Cc: cygwin@sources.redhat.com Subject: Re: CVS install Date: Wed, 20 Sep 2000 09:32:00 -0000 Message-id: <39C8E658.D2F9AB28@ece.gatech.edu> References: X-SW-Source: 2000-09/msg00714.html "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