This is the mail archive of the
mailing list for the Cygwin project.
Re: CVS install
- To: "Sagar R. Shah" <Sagar dot Shah at sid dot cam dot ac dot uk>
- Subject: Re: CVS install
- From: "Charles S. Wilson" <cwilson at ece dot gatech dot edu>
- Date: Wed, 20 Sep 2000 12:31:20 -0400
- CC: cygwin at sources dot redhat dot com
- References: <Pine.WNT.4.21.0009201122250.-435545@srs29>
"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
560421 -rw-rw-rw- 2 cwilson Users 3072 Dec 4 1999
560421 -rw-rw-rw- 2 cwilson Users 3072 Dec 4 1999
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
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,
1741 1730517 [main] CVS 1011
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
5555 1746989 [main] CVS 1011 fhandler_console::write: 3 = write_console
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
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
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org