This is the mail archive of the 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]

Re: CVS with pserver: Binary files get corrupted

Holger Spielmann wrote:

> Hello,
> due to company policy, I have to use Windows in my current project, so
> I started using Cygwin to get a halfway decent environment.
> I successfully managed to set up a CVS pserver on Cygwin. In our
> project, we want to add some JAR files to the CVS, so the frameworks
> API (here: Cocoon) can be assured to be on the same revision for all
> developers.
> But the jars arrive garbled in the repository, despite I added them
> with the -kb option. First I thought it might be related to the text
> mode I used for mounting the file systems, but transferring the
> repository didn't change anything, I even tried to import a new
> project from scratch.

The repository itself must be on a binary (unix) mounted drive -- within 
the conext of the service!  Since you are probably starting the pserver 
daemon from inetd, which is started under the *SYSTEM* user.  It 
(probably) doesn't matter where the checked-out or original-pre-import 
sources are, but the repository must be on a unix mount.

Try starting from scratch:

On repository machine:
   mount -b -s D:\my-repository /repository
(-s insures that this is a whole-system mount, so even the SYSTEM user 
will see it)

export CVSROOT=/repository
cvs init

And then try importing a new project.


[not snipped so your entire message appears in the correct mailing list archives]

> For all binary files, linefeed is replaced by CR/LF, and yes, it
> already happens when the files arrive in the repository.
> As I read in an older posting by Corinna Vinschen concerning ash,
> dated from April 2001, this might be related to the cvs pserver
> process opening its socket with O_TEXT. Alas, grepping thru the
> sources of cvs and inetutils showed me no place where I might try to
> patch.
> Using rsh is no opportunity because we get dynamic IPs, using ssh
> with client certificates would involve additional software and
> procedures, to which some of my collegues are not used to, and putting
> the repository on a Windows share is too damn slow and lacks any
> security.
> Ah, and did I mention the policy keeps me from just putting Debian on
> one of the boxes... :(
> Any ideas regarding this problem? A patch would be quite handy!

Unsubscribe info:
Bug reporting:

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