[Cool.  This should serve as the basis for a sanity.sh test case (for
the "hard linkage of 1.2 and working file do not match" and related
problems).  Now we just need the fix.

The general discussion of symlinks is also quite possibly worth a look.

-kingdon]

Date: Mon, 28 Sep 1998 13:00:15 +0200 (MET DST)
From: Martin Kacer <M.Kacer@sh.cvut.cz>
To: bug-cvs@gnu.org
Subject: PreservePermissions Bug Report


Hello developers:

   I started to use CVS about a month ago and I found it really great.
But there is one big problem for me and I think there must be much more
people who are affected by it --- the problem is with symbolic links.
In the manual there is a notice that I have two basic ways to work with
the links:
   - write some scripts that create all the links on each checkout
   - turn the PreservePermissions option on

   I do not like the first possibility so I decided to try to set the
PreservePermissions to `yes'. Unfortunately, I encountered many problems
and also some CVS crashes. It seems CVS does not detect symlinks right.
Moreover, the crashes appear even when there are absolutely no links in
the directory. It took me a lot of time to find an example that would
be short enough to be sent to you and that would always lead to the
crash of CVS. I think I have finally found it. The session is appended
on the end of this mail. Of course, it is possible that it will not
crash your installation of CVS but I think it always works. I could
send you core or anything else if it could be handy to you. But I
believe you will be able to reproduce the bug, if you want. My system
is Slackware Linux with 2.0.35 kernel, CVS version 1.10.

   Besides, I think there is a way of handling symlinks that would be
sufficient for me, and perhaps also for the others. In the manual there
is the following statement on the symbolic links:

        People periodically suggest that this behavior should be
        changed, but if there is a consensus on what it should be
        changed to, it doesn't seem to be apparent.

   I am sorry but I would like to add myself to those people... ;-))
What about handling symlinks just exactly as any usual file that's
content is the path the link is pointing to? For example the symlink
somefile.c -> ../any/dir/anotherfile.c
would be handled exactly the same way as the text file with the only
line containg the string "../any/dir/anotherfile.c". There could be
some option in config file that would set this behaviour.

   Well I do not think that I have discovered anything new. Probably
you have already rejected this possibility before. I just would like
to tell you that this behaviour (although it has its disadvanteges,
of course) would be perfectly sufficient for me. I guess there also
should be no implementation problem. Or is there some fact I have not
noticed? :-( Anyway, I do not want to preserve file permissions and
ownerships, I do not want to store device files in the repository and
do not want to use hardlinks --- I understand that handling hardlinks
is not easy. The only thing I want is to use a couple of symbolic links
in my project. And I need not to care whether the link points to
an existing file or not.

   Thank you for taking time. Yours
   Martin Kacer.


---------------- my config file ----------------

# Set this to "no" if pserver shouldn't check system users/passwords
#SystemAuth=no

# Set `PreservePermissions' to `yes' to save file status information
# in the repository.
PreservePermissions=yes

# Set `TopLevelAdmin' to `yes' to create a CVS directory at the top
# level of the new working directory when using the `cvs checkout'
# command.
#TopLevelAdmin=no

---------------- transcript of a buggy session ----------------

hostname:~$ mkdir buggy
hostname:~$ cd buggy/
hostname:~/buggy$ cat > buggy.c
some text inside ...
... this file
hostname:~/buggy$ cp buggy.c other.c
hostname:~/buggy$ cvs import -m import buggy one two
N buggy/buggy.c
N buggy/other.c

No conflicts created by this import

hostname:~/buggy$ cd ..
hostname:~$ rm -rf buggy/
hostname:~$ cvs co buggy
cvs checkout: Updating buggy
U buggy/buggy.c
U buggy/other.c
hostname:~$ cd buggy/
hostname:~/buggy$ touch other.c
hostname:~/buggy$ cvs ci -m commit1
cvs commit: Examining .
cvs commit: other.c: hard linkage of 1.1.1.1 and working file do not match
Checking in other.c;
/usr/local/cvsroot/buggy/other.c,v  <--  other.c
new revision: 1.2; previous revision: 1.1
done
hostname:~/buggy$ touch other.c
hostname:~/buggy$ cvs ci -m commit2
cvs commit: Examining .
hostname:~/buggy$ cvs status *.c
===================================================================
File: buggy.c           Status: Up-to-date

   Working revision:    1.1.1.1 Tue Sep 22 10:16:36 1998
   Repository revision: 1.1.1.1 /usr/local/cvsroot/buggy/buggy.c,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

cvs status: other.c: hard linkage of 1.2 and working file do not match
===================================================================
File: other.c           Status: Locally Modified

   Working revision:    1.2     Tue Sep 22 10:16:57 1998
   Repository revision: 1.2     /usr/local/cvsroot/buggy/other.c,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

hostname:~/buggy$ cvs ci -m commit2
cvs commit: Examining .
hostname:~/buggy$ cvs ci -f -m commit2
cvs commit: Examining .
Segmentation fault (core dumped)