[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 cd /tmp/CVSROOT touch 'a b' 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 [Exit 1] Then, repeat, but with a different checkout method: cd /tmp rm -rf CVSROOT cvs -d :ext:localhost:/tmp/x -Q co CVSROOT cd CVSROOT touch 'a b' cvs -n up Now, I get this: $ cvs -n up ? a unrecognized request `b' [Exit 1] ---------------------------------------- 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. */ void 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. */ assert (0); _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs