This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]