failed assertion when CVSROOT dir is a symlink

[Johannes Stezenbach]

CVS 1.10.7 and CVS 1.11:

The bug shows up for pserver, :fork: or local repository
access, when: 
- CVS root is in /home/cvsroot
- /cvsroot is a symbolic link to /home/cvsroot
- --allow-root and/or CVSROOT env. var. points to /cvsroot
(the repository was moved to a different disk)

checkout and commit work, but rdiff and rtag fail with:


cvs: lock.c:177: lock_name: Assertion `strncmp (repository,
 strlen (CVSroot_directory)))) == 0' failed. (1)


For the failed assertion, CVSroot_directory is '/cvsroot',
but repository is e.g. '/home/cvsroot/test', because do_recursion()
uses xgetwd().

Here's part of the stack-trace from gdb:
---------------
#3  0x40064d4a in __assert_fail () at assert.c:59
#4  0x8068901 in lock_name (repository=0x80d8908 "/home/cvsroot/test", 
    name=0x80b9f23 "#cvs.lock") at lock.c:177
#5  0x8069631 in set_lock (lock=0x80d1ef0, will_wait=1) at lock.c:730
#6  0x8068fbd in Reader_Lock (xrepository=0x80d8908 "/home/cvsroot/test")
    at lock.c:424
#7  0x8080f07 in do_recursion (frame=0xbffff264) at recurse.c:705
#8  0x8081b4f in unroll_files_proc (p=0x80d85b8, closure=0xbffff264)
    at recurse.c:1198
#9  0x80628cd in walklist (list=0x80d8350, proc=0x80819b0 <unroll_files_proc>, 
    closure=0xbffff264) at hash.c:370
#10 0x8080ae0 in start_recursion (fileproc=0x8073bd0 <patch_fileproc>, 
    filesdoneproc=0, direntproc=0x8074a90 <patch_dirproc>, dirleaveproc=0, 
    callerdat=0x0, argc=1, argv=0x80d8038, local=0, which=6, aflag=0, 
    readlock=1, update_preload=0x80d8068 "test", dosrcs=1) at recurse.c:344
#11 0x8073bae in patch_proc (argc=2, argv=0x80d8000, xwhere=0x0, mwhere=0x0, 
    mfile=0x0, shorten=0, local_specified=0, mname=0x80d7cf0 "test/test.txt", 
    msg=0x80c0cc2 "Patching") at patch.c:355
#12 0x8070893 in do_module (db=0x80d8088, mname=0x80d7cf0 "test/test.txt", 
    m_type=PATCH, msg=0x80c0cc2 "Patching", 
    callback_proc=0x8073780 <patch_proc>, where=0x0, shorten=0, 
    local_specified=0, run_module_prog=0, extra_arg=0x0) at modules.c:295
#13 0x8073746 in patch (argc=4, argv=0x80d7c8c) at patch.c:254
#14 0x806f11d in main (argc=4, argv=0x80d7c80) at main.c:1014
---------------

Our platform is Linux (various distributions and kernel versions).

I'm not shure how to fix this, but if you could give me some
advice on how to proceed, I would make a patch.
My guess is that expanding the symlink in parse_cvsroot()
would be the way to go, but I don't have the time to experiment
or analyse the CVS source in depth to find out...

Best regards,
Johannes Stezenbach


----
(1) the actual assertion I got was two pages long, due to
'gcc -O2' optimization of string functions via __inline__ and
macro expansions...