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@flex.com
Fri Mar 31 00:45:00 GMT 2006
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygcheck.out
Type: application/octet-stream
Size: 61457 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20060331/a5aff122/attachment.obj>
-------------- next part --------------
--
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/
More information about the Cygwin
mailing list