CVS 1.11.6: export bug in CVS on (LI/U)nix when CVSROOT env conta ins trailing slash

[Lane, Roy]

Hi,

Here's a bug I believe I've found in CVS that has been there at least since
1.11.2 and is present in the 1.11.6 release.  I think others have hit this
problem, but from my searches it's not clear that anyone has pinpointed the
problem yet.

The problem is that EXPORT does not work correctly (on UNIX/LINUX at least)
when the CVSROOT environment variable is set and the cvs root path in the
definition contains a trailing slash (/).  With CVSROOT defined this way,
the
export command results in the following error:

    > setenv CVSROOT /home/relane/hwlc/cvs/
    > cvs export -rHEAD hwlc
    cvs [export aborted]: cannot export into working directory

This problem ONLY occurs when CVSROOT is used to specify the repository.  If
"-d" is used on the command line, the EXPORT command works correctly with or
without the trailing slash.

With the bug, checkout_proc() is actually entered twice for the single
export
command.  The first time, the directory and CVS subdirectory are created,
but no
export is done.  The second time, the CVS subdirectory created by the first
call
is found and CVS complains because it thinks the export is being done in a
work
directory.  The command exits leaving only the CVS subdirectory without
doing
any export.  Under normal circumstances, checkout_proc() is only called once
for
a successful export.

The code fragment below shows how the problem occurs.  The "if" block is
only
entered if CVSROOT is defined and no repository was specified on the command
line (via -d).  'process_this_directory' becomes "false" because the
strcmp()
comparison fails due to the differences in the trailing slash.  This is what
prevents the export from completing during the first call to
checkout_proc().


1 of 2)   RECURSE.C - 1.11.6, line 570 in do_recursion():
---------------------------------------------------------

    if (
        /* If -d was specified, it should override CVS/Root.

           In the single-repository case, it is long-standing CVS behavior
           and makes sense - the user might want another access method,
           another server (which mounts the same repository), &c.

           In the multiple-repository case, -d overrides all CVS/Root
           files.  That is the only plausible generalization I can
           think of.  */
        CVSroot_cmdline == NULL

#ifdef SERVER_SUPPORT
        && ! server_active
#endif
        )
    {
        char *this_root = Name_Root ((char *) NULL, update_dir);
        if (this_root != NULL)
        {
            if (findnode (root_directories, this_root) == NULL)
            {
                /* Add it to our list. */

                Node *n = getnode ();
                n->type = NT_UNKNOWN;
                n->key = xstrdup (this_root);

                if (addnode (root_directories, n))
                    error (1, 0, "cannot add new CVSROOT %s", this_root);
        
            }

**********************************************************************
THE PROBLEM IS HERE (and in DUPLICATE code - see below):

        current_parsed_root->original = "/home/relane/hwlc/cvs/"
        this_root                     = "/home/relane/hwlc/cvs"
--------------------------------------------------------------^
they're the same directory but don't match becaue of the trailing '/'
'process_this_directory' becomes "FALSE".
**********************************************************************

            process_this_directory =
                    (strcmp (current_parsed_root->original, this_root) ==
0);

            free (this_root);
        }
    }

2 of 2)    RECURSE.C - 1.11.6, line 1037 in do_dir_proc():
----------------------------------------------------------

SAME SEGMENT OF CODE AS DESCRIBED ABOVE, 'process_this_directory' becomes
"FALSE".

********************************************************

I haven't proposed a fix for this, except that I would think that any
user-specified CVS root path should be "normalized" to remove trailing
and/or
duplicate directory separators (/) expecially if the path is to be compared
with
a cvs-generated directory path.

This isn't a major CVS bug, but it did cause me to spend a few hours trying
to
figure out why export appeared to be broken when CVS was upgraded from a
1.10
version.  From the looks of other bug reports/questions I've seen, others
must
have hit this also and probably spent some time investigating it.  I'm
hoping that someone will be able to get a fix in for a future release soon.

thanks,

Roy Lane
Intel