[this is using both the latest version of cvs from the trunk, updated
minutes ago, as well as cvs-1.12.9]
Merely creating a file with a newline in its name in any working
directory confuses cvs pretty seriously. Depending on the type
of server, it can `merely' fail with a cryptic `unrecognized request'
diagnostic, or abort on a failed assertion.
Since the offending code has been in server.c for quite some time,
(and there are even comments about the possibility that such newline-
containing file names could cause trouble), I wonder if this happens
so infrequently that it's not worth addressing the problem. IMHO,
it should be fixed -- or at least give better diagnostics so that
the user knows how to resolve the problem (simply remove the offending file).
I suggest that you consider encoding the file name by converting
the newline to `\n'. This cannot break any existing scripts,
since they wouldn't work in any case if there is a file name that
would make a difference.
Here's how to reproduce the failures:
cvs -d /tmp/x init
cvs -d /tmp/x co CVSROOT
cvs -n up
Here's what I get for the last command:
$ cvs -n up
cvs update: Updating .
cvs: server.c:7842: cvs_output_tagged: Assertion `0' failed.
? cvs [update aborted]: received abort signal
Then, repeat, but with a different checkout method:
rm -rf CVSROOT
cvs -d :ext:localhost:/tmp/x -Q co CVSROOT
cvs -n up
Now, I get this:
$ cvs -n up
unrecognized request `b'
For your convenience, here's the assert and associated comment:
/* Output TEXT, tagging it according to TAG. There are lots more
details about what TAG means in cvsclient.texi but for the simple
case (e.g. non-client/server), TAG is just "newline" to output a
newline (in which case TEXT must be NULL), and any other tag to
output normal text.
Note that there is no way to output either \0 or \n as part of TEXT. */
cvs_output_tagged (const char *tag, const char *text)
if (text != NULL && strchr (text, '\n') != NULL)
/* Uh oh. The protocol has no way to cope with this. For now
we dump core, although that really isn't such a nice
response given that this probably can be caused by newlines
in filenames and other causes other than bugs in CVS. Note
that we don't want to turn this into "MT newline" because
this case is a newline within a tagged item, not a newline
as extraneous sugar for the user. */
Bug-cvs mailing list