cvs 1.11.17 in command line server mode, OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005, problem with binary files

["Jay Abel" <jabel at flex dot com>]

I am using the cvs over ssh, using the ":ext:\home\..." form for the CVSROOT 
variable.  I have been experiencing problems with transferring binary files, 
though text files seem to behave correctly.

In the discussion that follows, the client is always cvs 1.11.17 running on 
cygwin.  The difference in behavior described between 'cygwin cvs server' 
and 'non-cygwin cvs server' means that the cvs server is a command-line cvs 
client/server running on the local machine or a remote unix machine, 
respectively.

I would like to be more specific than 'problems' but the precise failure 
mode seems to depend on the actual contents of the repository, and/or the 
contents of a particular file.

The behaviors include but aren't limited to:

1. cvs in command line server mode seems to just hang.  The process is 
there, but stops transferring data.
2. cvs reports 'broken pipe'
3. cvs repots an error in the protocol, "Invalid command: xxxxxx' where 
xxxxxx is a random snippet of the offending file, not any expected command.

When connecting to another non-cygwin host running CVS 1.11.19 
(client/server) the identical set of files can be imported, retrieved with 
get, modified, added, updated and committed without error.

The aberrant behavior only occurs when transferring binary files, which 
unless I am mistaken are added/imported with the `-kb' option set.

This problem is not related to the mkdir issue already reported by others 
and resolved by Messr's Faylor and Petchanski.  I also had that problem but 
fixed it by downloading a cvs snapshot.  I notice that it is now permanently 
fixed in the latest download, but since this presently reported behavior has 
not been fixed, I felt now is a good time to bring it up without fear that 
this will be confused for the other, now repaired, problem.

I am happy to make my server available to a developer working on the problem 
if they are unable to reproduce the problem.

Here are the steps I use (from memory, please don't flame if there are 
slight errors in the command sequence).

1. Create a directory /home/testrepository with my default permissions (my 
username as owner, Administrator as group.  I have also tried SYSTEM as 
owner, this doesn't seem to make a difference).

$ cvs -d ":ext:jayabel.com:/home/spring2006/" init
$ mkdir cvstest
$ cd ~/cvstest
$ cvs -d ":ext:jayabel.com:/home/spring2006/" get .
$ cd CVSROOT
$ cp <elswhere>/CVSROOT/cvswrappers .
$ cvs up
M cvswrappers
$ cvs commit -m 'update wrappers'
$ cd ~/phys274/
% cvs -t -d ":ext:jayabel.com:/home/spring2006/" import phys274 LOCAL IMPORT
-> main loop with CVSROOT=:ext:jayabel.com:/home/spring2006/
-> Starting server: /bin/ssh jayabel.com cvs server
-> system('vim' '/tmp//cvsdk5c24')
-> unlink_file(/tmp//cvsdk5c24)
I phys274/homework/CVS
-> Sending file `q8s7.xls' to server
-> Sending file `q8s9.xmcd' to server
I phys274/homework/weekly/CVS
I phys274/homework/weekly/week2/CVS
-> Sending file `Q1R2.xmcd' to server
I phys274/homework/weekly/week4/CVS
-> Sending file `q4r3.dfw' to server
-> Sending file `week4-2.dfw' to server
I phys274/homework/weekly/week5/CVS
-> Sending file `q5t1.txt' to server
-> Sending file `q6r2.dfw' to server
-> Sending file `p2.fig' to server
I phys274/homework/weekly/week6/p2.fig.bak
-> Sending file `q8A1.xls' to server
-> Sending file `align.eps' to server
-> Sending file `align.fig' to server
-> Sending file `chamber.eps' to server
-> Sending file `chamber.fig' to server
-> Sending file `chamber.pdf' to server
-> Sending file `cooked.tex' to server
I phys274/lab/lab3-michelson/CVS
-> Sending file `data.m' to server
-> Sending file `data.pdf' to server
-> Sending file `data.ps' to server
-> Sending file `fit.log' to server
-> Sending file `graph.eps' to server
-> Sending file `graph.fig' to server
-> Sending file `graph.gpl' to server
-> Sending file `graph2.eps' to server
-> Sending file `graph2.fig' to server
-> Sending file `graph2.gpl' to server
-> Sending file `makefile' to server
-> Sending file `raw.tex' to server
-> Sending file `report.aux' to server
-> Sending file `report.dvi' to server
-> Sending file `report.log' to server
-> Sending file `report.pdf' to server
-> Sending file `report.ps' to server
[snip]
-> Sending file `s4.dat' to server
-> Sending file `setup.eps' to server
-> Sending file `setup.fig' to server
-> Sending file `setup.pdf' to server
-> Sending file `angle error.dfw' to server
I phys274/lab/lab3-michelson/refs/CVS
-> Sending file `data.gpl' to server
-> Sending file `error analysis.dfw' to server
-> Sending file `PASCO.pdf' to server
-> Sending file `s1.csv' to server
-> Sending file `s1.xls' to server
-> Sending file `trial1.xls' to server
-> Sending file `trial2.xls' to server
-> Sending file `weighted.xls' to server
-> Sending file `gap-Ge.pdf' to server
-> Sending file `lab4.xls' to server
-> Sending file `lab4_before.xls' to server
-> Sending file `thermocouple.pdf' to server
-> Sending file `abc.gpl' to server
-> Sending file `constb.tex' to server
-> Sending file `consti.tex' to server
I phys274/lab/lab6-hall/CVS
-> Sending file `data.m' to server
I phys274/lab/lab6-hall/data.m~
-> Sending file `endeffect.eps' to server
-> Sending file `endeffect.png' to server
-> Sending file `fit.log' to server
-> Sending file `golikova.eps' to server
-> Sending file `golikova.png' to server
-> Sending file `graph1.eps' to server
-> Sending file `graph1.gpl' to server
I phys274/lab/lab6-hall/graph1.gpl~
-> Sending file `graph1.tex' to server
-> Sending file `graph2.eps' to server
-> Sending file `graph2.gpl' to server
-> Sending file `graph2.tex' to server
-> Sending file `graph3.eps' to server
-> Sending file `graph3.gpl' to server
-> Sending file `graph3.tex' to server
-> Sending file `halleffect.fig' to server
I phys274/lab/lab6-hall/halleffect.fig.bak
-> Sending file `halleffect.pstex' to server
-> Sending file `halleffect.pstex_t' to server
-> Sending file `makefile' to server
I phys274/lab/lab6-hall/makefile~
-> Sending file `minusb.tex' to server
-> Sending file `plusb.tex' to server
-> Sending file `rect.fig' to server
-> Sending file `rect.pstex' to server
-> Sending file `rect.pstex_t' to server
-> Sending file `report.aux' to server
-> Sending file `report.dvi' to server
-> Sending file `report.log' to server
-> Sending file `report.pdf' to server

whereupon there is no further output.

It is interesting that several files appear to be skipped.  Shouldn't I see 
one `I blah/blah/blah' for every file?  In any case the file report.pdf 
seems to deal the death blow.  Yes, it is quite large, but no amount of 
waiting time seems to be sufficient.

In other cases, I've received the message "broken pipe", or something to the 
effect of "unrecognized command" followed by a piece of the file.

The /tmp directory is mounted in binmode, but the repository and upload 
directories are both textmode.  I've tried various permutations, including 
mounting all directories in binmode, but there still seems to be a problem.

Technically, .pdf should be a text file but I've noticed that some versions 
of adobe reader barf if the newlines are replaced with CRLF's, so .pdf is 
indicated as -kb in my cvswrappers file.

I am not a CVS developer, so you can safely ignore everything I have to say, 
but if I had the faintest idea where to start, I would probably try to make 
cvs open the archives in unix format no matter what.  Because the archives 
can contain binary files with only a few characters escaped, it seems proper 
to me that they should be treated as binary files.

Also, cvs should always revert to unix/binary interface when it is the 
server, so that the client always sees the same interface.  Why? one less 
combination to test.  Since the client cannot (should not) possibly know the 
text format of the remote server, and since cvs only talks to itself, 
wouldn't it make life easier if it just always conducted the client/server 
dialog over a binary mode connection, and just pick a local line end 
convention and stick with it (makes sense it should be unix, not DOS, if for 
no other reason than it is much easier to code and test).  Finally, the 
client SHOULD know whether files are binary or text, but again, it shouldn't 
do any monkeying with the file.  It should just open the file as "wt" if it 
is text or "wb" if it is binary, and let Cygwin (or whatever local OS) do 
the conversion.

Finally, has anyone checked to see if CVS is trying to lseek within text 
files?  Couldn't that just make a mess of things?

Thank you all for your kind consideration.  This is my first post to 
cygwin@cygwin.com, so please be gentle with your corrections, I've tried to 
follow instructions but I may have missed some of the finer points.

Jay Abel

Attachment: cygcheck.out
Description: Binary data

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/