Re: Fwd: Re: CygWin adding CRs, hurting CVS client/server communications?
Quoting from the document referenced below: We have tried these commands but they have not quite worked for us mount -f -t -s c:\\cygwin\\lib /usr/lib mount -f -t -s c:\\cygwin\\bin /usr/bin mount -f -t -s c:\\cygwin / mount -f -t c: /cygdrive/c The reason the commands didn't work was because the last command is just plain wrong. The correct command (for their purposes) would have been mount -c -t -s /cygdrive after which there is no need to re-mount each drive separately (or reinstall Cygwin). Plus, there's a typo on that page (although in the text that would be made redundant by the correct command above). I didn't find any information on the page on how to notify the maintainers of these errors, but if anyone wants to dig deeper, it would be nice. The above is one of the main reasons why we frown upon external documentation. Igor On Mon, 30 Jun 2003 [EMAIL PROTECTED] wrote: Well, I take that back...someone pointed me to http://www.gigascale.org/softdevel/faq/23.html, which contains instructions for reinstalling CygWin with text mode set to DOS, which actually fixes the problem (the remount procedure didn't work, as is warned in the article). All I did was run the setup utility, selected DOS text mode, and selected the base/cygwin and devel/cvs packages for reinstallation...works like a charm now. The contents of this article might be good fodder for the FAQs. Cheers! At 08:17 AM 6/30/2003, [EMAIL PROTECTED] wrote: Understood. I've compiled CVS from source on my server (which is how I tracked down and confirmed the CRLF issue), but am not set up to compile anything on the Windows client. I doubt I'll have time in the near future to try, so for now I'll have to ditch CVS/SSH, and once I truly need version control again, either see if it's working again or go with a commercial solution. No big deal for now...thanks for trying though. Toscani At 01:55 PM 6/28/2003, Charles Wilson wrote: Sorry, guys, but I can't reproduce this. Client: openssh 3.6.1p1-2 cvs 1.11.5-1 cygwin 1.3.22-1 :pserver: and :ext:(CVS_RSH=ssh) mode, with server sources.redhat.com Server is running: Concurrent Versions System (CVS) 1.11.1p1 (client/server) (with local hacks) OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f - Because I can't reproduce this, somebody who is experiencing the problem is going to have to track it down and provide a detailed (e.g. this code right here: ... is wrong...) bug analysis. I can't fix what I can't see. --Chuck cvs maintainer [EMAIL PROTECTED] wrote: Forgot to CC this to the list. Date: Sat, 28 Jun 2003 10:37:51 -0600 To: Van Rooyen G-J [EMAIL PROTECTED] [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Re: CygWin adding CRs, hurting CVS client/server communications? I've seen the same symptoms...output is garbled because CRs are left in the strings CVS interprets, and it spits them out after concatenating them...so you wind up with lines like textCRtextNL...I've dumped the output and confirmed that this is what is happening. Another good point...I am using the CygWin CVS client, not WinCVS. Toscani At 06:49 AM 6/28/2003, you wrote: I have exactly the same problem as Toscani describes. Last week I did a routine update on my Cygwin packages, and my Cygwin CVS client (which worked fine the previous day) could not authenticate with the server any more. The login command works fine, but any subsequent operations fail to authenticate. Furthermore, the server error message is garbled, as if a CR/LF problem occurred. Client: Cygwin on WinXP Server: Redhat (not sure of the version) Authentication: Plain pserver, no SSH. Judging from Patrick's response (who uses WinCVS, and not Cygwin CVS) the problem lies somewhere in the Cygwin CVS client, not in Cygwin SSH. G-J --- in response to: --- Works like a charm here, both for binmode and textmode mounts. My system: Win2k, WinCVS and Cygwin SSH The problem mentioned in your mailing list reference was fixed long time ago. Do your line endings change as well if you scp a textfile from your client to your server? If yes, then we have indeed an ssh issue on WinXP platforms. Otherwise your problem must lie somewhere else. Patrick --- in response to: --- Hey folx...currently using OpenSSH under CygWin on an XP box to communicate with a CVS server on a Linux box. Recently upgraded my CygWin installation (1.3.22(0.78/3/2), including OpenSSH to v3.6.1p1 (the latest available under CygWin), and now CVS client/server communications over SSH (CVS_RSH=ssh) don't work. I've tracked the problem deep enough to suspect that SOMETHING in CygWin converts LF to CR+LF line terminators across SSH. This pretty much hoses CVS client/server communications, as the CVS server interprets all incoming lines as byte strings including a CR at the end (it treats LF
Re: Fwd: Re: CygWin adding CRs, hurting CVS client/server communications?
Understood. I've compiled CVS from source on my server (which is how I tracked down and confirmed the CRLF issue), but am not set up to compile anything on the Windows client. I doubt I'll have time in the near future to try, so for now I'll have to ditch CVS/SSH, and once I truly need version control again, either see if it's working again or go with a commercial solution. No big deal for now...thanks for trying though. Toscani At 01:55 PM 6/28/2003, Charles Wilson wrote: Sorry, guys, but I can't reproduce this. Client: openssh 3.6.1p1-2 cvs 1.11.5-1 cygwin 1.3.22-1 :pserver: and :ext:(CVS_RSH=ssh) mode, with server sources.redhat.com Server is running: Concurrent Versions System (CVS) 1.11.1p1 (client/server) (with local hacks) OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f - Because I can't reproduce this, somebody who is experiencing the problem is going to have to track it down and provide a detailed (e.g. this code right here: ... is wrong...) bug analysis. I can't fix what I can't see. --Chuck cvs maintainer [EMAIL PROTECTED] wrote: Forgot to CC this to the list. Date: Sat, 28 Jun 2003 10:37:51 -0600 To: Van Rooyen G-J [EMAIL PROTECTED] [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Re: CygWin adding CRs, hurting CVS client/server communications? I've seen the same symptoms...output is garbled because CRs are left in the strings CVS interprets, and it spits them out after concatenating them...so you wind up with lines like textCRtextNL...I've dumped the output and confirmed that this is what is happening. Another good point...I am using the CygWin CVS client, not WinCVS. Toscani At 06:49 AM 6/28/2003, you wrote: I have exactly the same problem as Toscani describes. Last week I did a routine update on my Cygwin packages, and my Cygwin CVS client (which worked fine the previous day) could not authenticate with the server any more. The login command works fine, but any subsequent operations fail to authenticate. Furthermore, the server error message is garbled, as if a CR/LF problem occurred. Client: Cygwin on WinXP Server: Redhat (not sure of the version) Authentication: Plain pserver, no SSH. Judging from Patrick's response (who uses WinCVS, and not Cygwin CVS) the problem lies somewhere in the Cygwin CVS client, not in Cygwin SSH. G-J --- in response to: --- Works like a charm here, both for binmode and textmode mounts. My system: Win2k, WinCVS and Cygwin SSH The problem mentioned in your mailing list reference was fixed long time ago. Do your line endings change as well if you scp a textfile from your client to your server? If yes, then we have indeed an ssh issue on WinXP platforms. Otherwise your problem must lie somewhere else. Patrick --- in response to: --- Hey folx...currently using OpenSSH under CygWin on an XP box to communicate with a CVS server on a Linux box. Recently upgraded my CygWin installation (1.3.22(0.78/3/2), including OpenSSH to v3.6.1p1 (the latest available under CygWin), and now CVS client/server communications over SSH (CVS_RSH=ssh) don't work. I've tracked the problem deep enough to suspect that SOMETHING in CygWin converts LF to CR+LF line terminators across SSH. This pretty much hoses CVS client/server communications, as the CVS server interprets all incoming lines as byte strings including a CR at the end (it treats LF as the actual terminator)...especially bad for pathname interpretation, but lots of other things may be affected as well. I've tried altering the CVS server code to eat the extra CRs, but too many other things break (including file data exchange I'd bet...can't tell which CRs are valid data and which are inserted by the system) for that to be effective. Found a reference in the mailing list archives to a similar problem someone was having last October, but the solution was to install a snapshot from that time period which seems to be no longer available. I'm wondering if the fix for this issue never found its way into more recent versions of the CygWin system components? I've upgraded CVS on both client and server, but based on my testing, I don't think CVS itself is adding the CRs...please flame if I'm wrong on that one. g Not sure what else to do right now but do without version control for a bit...any better ideas? - Toscani -- 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/
Re: Fwd: Re: CygWin adding CRs, hurting CVS client/server communications?
Well, I take that back...someone pointed me to http://www.gigascale.org/softdevel/faq/23.html, which contains instructions for reinstalling CygWin with text mode set to DOS, which actually fixes the problem (the remount procedure didn't work, as is warned in the article). All I did was run the setup utility, selected DOS text mode, and selected the base/cygwin and devel/cvs packages for reinstallation...works like a charm now. The contents of this article might be good fodder for the FAQs. Cheers! At 08:17 AM 6/30/2003, [EMAIL PROTECTED] wrote: Understood. I've compiled CVS from source on my server (which is how I tracked down and confirmed the CRLF issue), but am not set up to compile anything on the Windows client. I doubt I'll have time in the near future to try, so for now I'll have to ditch CVS/SSH, and once I truly need version control again, either see if it's working again or go with a commercial solution. No big deal for now...thanks for trying though. Toscani At 01:55 PM 6/28/2003, Charles Wilson wrote: Sorry, guys, but I can't reproduce this. Client: openssh 3.6.1p1-2 cvs 1.11.5-1 cygwin 1.3.22-1 :pserver: and :ext:(CVS_RSH=ssh) mode, with server sources.redhat.com Server is running: Concurrent Versions System (CVS) 1.11.1p1 (client/server) (with local hacks) OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f - Because I can't reproduce this, somebody who is experiencing the problem is going to have to track it down and provide a detailed (e.g. this code right here: ... is wrong...) bug analysis. I can't fix what I can't see. --Chuck cvs maintainer [EMAIL PROTECTED] wrote: Forgot to CC this to the list. Date: Sat, 28 Jun 2003 10:37:51 -0600 To: Van Rooyen G-J [EMAIL PROTECTED] [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Re: CygWin adding CRs, hurting CVS client/server communications? I've seen the same symptoms...output is garbled because CRs are left in the strings CVS interprets, and it spits them out after concatenating them...so you wind up with lines like textCRtextNL...I've dumped the output and confirmed that this is what is happening. Another good point...I am using the CygWin CVS client, not WinCVS. Toscani At 06:49 AM 6/28/2003, you wrote: I have exactly the same problem as Toscani describes. Last week I did a routine update on my Cygwin packages, and my Cygwin CVS client (which worked fine the previous day) could not authenticate with the server any more. The login command works fine, but any subsequent operations fail to authenticate. Furthermore, the server error message is garbled, as if a CR/LF problem occurred. Client: Cygwin on WinXP Server: Redhat (not sure of the version) Authentication: Plain pserver, no SSH. Judging from Patrick's response (who uses WinCVS, and not Cygwin CVS) the problem lies somewhere in the Cygwin CVS client, not in Cygwin SSH. G-J --- in response to: --- Works like a charm here, both for binmode and textmode mounts. My system: Win2k, WinCVS and Cygwin SSH The problem mentioned in your mailing list reference was fixed long time ago. Do your line endings change as well if you scp a textfile from your client to your server? If yes, then we have indeed an ssh issue on WinXP platforms. Otherwise your problem must lie somewhere else. Patrick --- in response to: --- Hey folx...currently using OpenSSH under CygWin on an XP box to communicate with a CVS server on a Linux box. Recently upgraded my CygWin installation (1.3.22(0.78/3/2), including OpenSSH to v3.6.1p1 (the latest available under CygWin), and now CVS client/server communications over SSH (CVS_RSH=ssh) don't work. I've tracked the problem deep enough to suspect that SOMETHING in CygWin converts LF to CR+LF line terminators across SSH. This pretty much hoses CVS client/server communications, as the CVS server interprets all incoming lines as byte strings including a CR at the end (it treats LF as the actual terminator)...especially bad for pathname interpretation, but lots of other things may be affected as well. I've tried altering the CVS server code to eat the extra CRs, but too many other things break (including file data exchange I'd bet...can't tell which CRs are valid data and which are inserted by the system) for that to be effective. Found a reference in the mailing list archives to a similar problem someone was having last October, but the solution was to install a snapshot from that time period which seems to be no longer available. I'm wondering if the fix for this issue never found its way into more recent versions of the CygWin system components? I've upgraded CVS on both client and server, but based on my testing, I don't think CVS itself is adding the CRs...please flame if I'm wrong on that one. g Not sure what else to do right now but do without version control for a bit...any better ideas? - Toscani -- Unsubscribe info: http://cygwin.com/ml
Re: Fwd: Re: CygWin adding CRs, hurting CVS client/server communications?
[EMAIL PROTECTED] wrote: Well, I take that back...someone pointed me to http://www.gigascale.org/softdevel/faq/23.html, which contains instructions for reinstalling CygWin with text mode set to DOS, which actually fixes the problem (the remount procedure didn't work, as is warned in the article). All I did was run the setup utility, selected DOS text mode, and selected the base/cygwin and devel/cvs packages for reinstallation...works like a charm now. The contents of this article might be good fodder for the FAQs. Cheers! I'd suggest this is the wrong direction to head in this case for at least a few of reasons: 1. This hasn't really risen to the level of a FAQ. 2. The problem is ill-defined at least and isn't shared by the vast majority. 3. It's not at all clear that the problem isn't fixable if it were better understood. Perhaps someone seeing this problem could spend a little more time with it and see if a solution can be found that makes any documentation of it unnecessary. That would be a real big help. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/
Re: Fwd: Re: CygWin adding CRs, hurting CVS client/server communications?
Larry Hall wrote: [EMAIL PROTECTED] wrote: Well, I take that back...someone pointed me to http://www.gigascale.org/softdevel/faq/23.html, which contains instructions for reinstalling CygWin with text mode set to DOS, which actually fixes the problem (the remount procedure didn't work, as is warned in the article). All I did was run the setup utility, selected DOS text mode, and selected the base/cygwin and devel/cvs packages for reinstallation...works like a charm now. The contents of this article might be good fodder for the FAQs. Cheers! I'm glad you found a solution that works for you. However, I do not believe it to be a general solution. I repeat, I cannot reproduce this problem. I am using all binary mounts -- **and always have**. This means that my local working directory contains files that do not have ^M's. Naturally, the files on the remote, linux-hosted repository do not have ^M's. No translation is needed, and no translation is performed. Checkouts, updates, diffs, in both anonymous :pserver: and authenticated ssh mode all work fine. Neither cygwin nor ssh nor cvs is omniscient. If you introduce ^M's into the local working directory -- perhaps by using notepad? -- then naturally those will show up as diffs when compared against the server. You can HIDE those ^M-derived diffs by setting the mount mode to 'DOS' -- but I wouldn't recommend it as a general solution unless you really know what you're doing, and what the ramifications are (even I do not claim to know ALL of the ramifications). I'd suggest this is the wrong direction to head in this case for at least a few of reasons: 1. This hasn't really risen to the level of a FAQ. 2. The problem is ill-defined at least and isn't shared by the vast majority. 3. It's not at all clear that the problem isn't fixable if it were better understood. Perhaps someone seeing this problem could spend a little more time with it and see if a solution can be found that makes any documentation of it unnecessary. That would be a real big help. Actually, I believe the problem here is the following: originally, mount mode was binary. cvs checkout (over ssh) was performed. local working-dir files were non-^M. -- and then something happened -- maybe notepad. Maybe the recent perl update with all of the PERLIO= mess caused automake/autoconf to behave funky and add ^M's. Maybe vi or xemacs was accidentally set to dos mode. But somehow, someway, some OTHER program introduced ^M's. And the ssh/cvs/cygwin faithfully (with binary mounts) indicates those differences. Now, this is NOT how cvs is advertised to work. It is SUPPOSED to open the local files, strip off ^M's if there are any (*) and handle all communication with the server in unix mode. When appropriate (on a windows sytem, or on cygwin with dos mounts) then it should add the ^M's back when writing to disk. (**) (*) when in cvs binary mode (e.g. don't replace keywords; distinct from *cygwin* binary or fopen(rb)/open(O_BINARY) mode), then this smart line-ending translation should not be done. (**) when accessing a local repository (as distinct from a local working dir), then ALL on disk files are supposed to be stored in ^M-less mode. (except of course those that are in cvs -kb / -ko mode). Repositories are always unixmode. --- What I think this means, is that cvs takes great care to do for cygwin what cygwin is already doing -- which is what causes the conflict, because cygwin's translation and cvs's translation are stepping on each other. I THINK cvs-on-cygwin should be modified to do the following: 1) Always open all on-disk files in binary (fopen(O_BINARY) open(rb/wb) ) mode. ALWAYS, regardless of mount mode 2) Use the mount mode to indicate whether *cvs* should turn on its internal translation stuff. E.g. mount=dosmode means I'm a DOSish system, do the DOSish thing when accessing the disk, mount=unixmode means I'm a unixish system, do the unixish thing when accessing the disk. (for working dirs only, because repositories are always unixmode) 3) ***IF*** the file in question is in cvs binary mode (-kb, -ko), then DON'T do translation stuff EVEN on DOSish systems (e.g. even if mount mode = DOS, don't try to translate. You really don't want to strip ^M's out of png or gif files... In other words, I'm advocating basically (1) letting cvs turn off cygwin's mount mode stuff -- but (2) use the mount mode as a cue for whether to turn on cvs's internal translation stuff. Blindly linking cvs.exe against -lbinmode will take care of (1) [a rather brute force option...I'd rather do it right eventually] but it will take more effort to do (2) correctly. And then we get to test. and test and test and test... -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ:
Re: CygWin adding CRs, hurting CVS client/server communications?
Works like a charm here, both for binmode and textmode mounts. My system: Win2k, WinCVS and Cygwin SSH The problem mentioned in your mailing list reference was fixed long time ago. Do your line endings change as well if you scp a textfile from your client to your server? If yes, then we have indeed an ssh issue on WinXP platforms. Otherwise your problem must lie somewhere else. Patrick Hey folx...currently using OpenSSH under CygWin on an XP box to communicate with a CVS server on a Linux box. Recently upgraded my CygWin installation (1.3.22(0.78/3/2), including OpenSSH to v3.6.1p1 (the latest available under CygWin), and now CVS client/server communications over SSH (CVS_RSH=ssh) don't work. I've tracked the problem deep enough to suspect that SOMETHING in CygWin converts LF to CR+LF line terminators across SSH. This pretty much hoses CVS client/server communications, as the CVS server interprets all incoming lines as byte strings including a CR at the end (it treats LF as the actual terminator)...especially bad for pathname interpretation, but lots of other things may be affected as well. I've tried altering the CVS server code to eat the extra CRs, but too many other things break (including file data exchange I'd bet...can't tell which CRs are valid data and which are inserted by the system) for that to be effective. Found a reference in the mailing list archives to a similar problem someone was having last October, but the solution was to install a snapshot from that time period which seems to be no longer available. I'm wondering if the fix for this issue never found its way into more recent versions of the CygWin system components? I've upgraded CVS on both client and server, but based on my testing, I don't think CVS itself is adding the CRs...please flame if I'm wrong on that one. g Not sure what else to do right now but do without version control for a bit...any better ideas? - Toscani -- 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/
Re: CygWin adding CRs, hurting CVS client/server communications?
I have exactly the same problem as Toscani describes. Last week I did a routine update on my Cygwin packages, and my Cygwin CVS client (which worked fine the previous day) could not authenticate with the server any more. The login command works fine, but any subsequent operations fail to authenticate. Furthermore, the server error message is garbled, as if a CR/LF problem occurred. Client: Cygwin on WinXP Server: Redhat (not sure of the version) Authentication: Plain pserver, no SSH. Judging from Patrick's response (who uses WinCVS, and not Cygwin CVS) the problem lies somewhere in the Cygwin CVS client, not in Cygwin SSH. G-J --- in response to: --- Works like a charm here, both for binmode and textmode mounts. My system: Win2k, WinCVS and Cygwin SSH The problem mentioned in your mailing list reference was fixed long time ago. Do your line endings change as well if you scp a textfile from your client to your server? If yes, then we have indeed an ssh issue on WinXP platforms. Otherwise your problem must lie somewhere else. Patrick --- in response to: --- Hey folx...currently using OpenSSH under CygWin on an XP box to communicate with a CVS server on a Linux box. Recently upgraded my CygWin installation (1.3.22(0.78/3/2), including OpenSSH to v3.6.1p1 (the latest available under CygWin), and now CVS client/server communications over SSH (CVS_RSH=ssh) don't work. I've tracked the problem deep enough to suspect that SOMETHING in CygWin converts LF to CR+LF line terminators across SSH. This pretty much hoses CVS client/server communications, as the CVS server interprets all incoming lines as byte strings including a CR at the end (it treats LF as the actual terminator)...especially bad for pathname interpretation, but lots of other things may be affected as well. I've tried altering the CVS server code to eat the extra CRs, but too many other things break (including file data exchange I'd bet...can't tell which CRs are valid data and which are inserted by the system) for that to be effective. Found a reference in the mailing list archives to a similar problem someone was having last October, but the solution was to install a snapshot from that time period which seems to be no longer available. I'm wondering if the fix for this issue never found its way into more recent versions of the CygWin system components? I've upgraded CVS on both client and server, but based on my testing, I don't think CVS itself is adding the CRs...please flame if I'm wrong on that one. g Not sure what else to do right now but do without version control for a bit...any better ideas? - Toscani
Fwd: Re: CygWin adding CRs, hurting CVS client/server communications?
Forgot to CC this to the list. Date: Sat, 28 Jun 2003 10:34:52 -0600 To: Patrick Eisenacher [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Re: CygWin adding CRs, hurting CVS client/server communications? I've just tried scp'ing a text file containing CRNL line terminators...the copy of the file on the server is unchanged, i.e., it still has CRNLs. So I guess this means the problem isn't with SSH. It's just weird that it popped up immediately after a CygWin update...could there be something else in CygWin doing this? Hmmm... Toscani At 05:15 AM 6/28/2003, you wrote: Works like a charm here, both for binmode and textmode mounts. My system: Win2k, WinCVS and Cygwin SSH The problem mentioned in your mailing list reference was fixed long time ago. Do your line endings change as well if you scp a textfile from your client to your server? If yes, then we have indeed an ssh issue on WinXP platforms. Otherwise your problem must lie somewhere else. Patrick Hey folx...currently using OpenSSH under CygWin on an XP box to communicate with a CVS server on a Linux box. Recently upgraded my CygWin installation (1.3.22(0.78/3/2), including OpenSSH to v3.6.1p1 (the latest available under CygWin), and now CVS client/server communications over SSH (CVS_RSH=ssh) don't work. I've tracked the problem deep enough to suspect that SOMETHING in CygWin converts LF to CR+LF line terminators across SSH. This pretty much hoses CVS client/server communications, as the CVS server interprets all incoming lines as byte strings including a CR at the end (it treats LF as the actual terminator)...especially bad for pathname interpretation, but lots of other things may be affected as well. I've tried altering the CVS server code to eat the extra CRs, but too many other things break (including file data exchange I'd bet...can't tell which CRs are valid data and which are inserted by the system) for that to be effective. Found a reference in the mailing list archives to a similar problem someone was having last October, but the solution was to install a snapshot from that time period which seems to be no longer available. I'm wondering if the fix for this issue never found its way into more recent versions of the CygWin system components? I've upgraded CVS on both client and server, but based on my testing, I don't think CVS itself is adding the CRs...please flame if I'm wrong on that one. g Not sure what else to do right now but do without version control for a bit...any better ideas? - Toscani -- 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/ -- 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/
Fwd: Re: CygWin adding CRs, hurting CVS client/server communications?
Forgot to CC this to the list. Date: Sat, 28 Jun 2003 10:37:51 -0600 To: Van Rooyen G-J [EMAIL PROTECTED] [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Re: CygWin adding CRs, hurting CVS client/server communications? I've seen the same symptoms...output is garbled because CRs are left in the strings CVS interprets, and it spits them out after concatenating them...so you wind up with lines like textCRtextNL...I've dumped the output and confirmed that this is what is happening. Another good point...I am using the CygWin CVS client, not WinCVS. Toscani At 06:49 AM 6/28/2003, you wrote: I have exactly the same problem as Toscani describes. Last week I did a routine update on my Cygwin packages, and my Cygwin CVS client (which worked fine the previous day) could not authenticate with the server any more. The login command works fine, but any subsequent operations fail to authenticate. Furthermore, the server error message is garbled, as if a CR/LF problem occurred. Client: Cygwin on WinXP Server: Redhat (not sure of the version) Authentication: Plain pserver, no SSH. Judging from Patrick's response (who uses WinCVS, and not Cygwin CVS) the problem lies somewhere in the Cygwin CVS client, not in Cygwin SSH. G-J --- in response to: --- Works like a charm here, both for binmode and textmode mounts. My system: Win2k, WinCVS and Cygwin SSH The problem mentioned in your mailing list reference was fixed long time ago. Do your line endings change as well if you scp a textfile from your client to your server? If yes, then we have indeed an ssh issue on WinXP platforms. Otherwise your problem must lie somewhere else. Patrick --- in response to: --- Hey folx...currently using OpenSSH under CygWin on an XP box to communicate with a CVS server on a Linux box. Recently upgraded my CygWin installation (1.3.22(0.78/3/2), including OpenSSH to v3.6.1p1 (the latest available under CygWin), and now CVS client/server communications over SSH (CVS_RSH=ssh) don't work. I've tracked the problem deep enough to suspect that SOMETHING in CygWin converts LF to CR+LF line terminators across SSH. This pretty much hoses CVS client/server communications, as the CVS server interprets all incoming lines as byte strings including a CR at the end (it treats LF as the actual terminator)...especially bad for pathname interpretation, but lots of other things may be affected as well. I've tried altering the CVS server code to eat the extra CRs, but too many other things break (including file data exchange I'd bet...can't tell which CRs are valid data and which are inserted by the system) for that to be effective. Found a reference in the mailing list archives to a similar problem someone was having last October, but the solution was to install a snapshot from that time period which seems to be no longer available. I'm wondering if the fix for this issue never found its way into more recent versions of the CygWin system components? I've upgraded CVS on both client and server, but based on my testing, I don't think CVS itself is adding the CRs...please flame if I'm wrong on that one. g Not sure what else to do right now but do without version control for a bit...any better ideas? - Toscani -- 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/
Re: Fwd: Re: CygWin adding CRs, hurting CVS client/server communications?
Sorry, guys, but I can't reproduce this. Client: openssh 3.6.1p1-2 cvs 1.11.5-1 cygwin 1.3.22-1 :pserver: and :ext:(CVS_RSH=ssh) mode, with server sources.redhat.com Server is running: Concurrent Versions System (CVS) 1.11.1p1 (client/server) (with local hacks) OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f - Because I can't reproduce this, somebody who is experiencing the problem is going to have to track it down and provide a detailed (e.g. this code right here: ... is wrong...) bug analysis. I can't fix what I can't see. --Chuck cvs maintainer [EMAIL PROTECTED] wrote: Forgot to CC this to the list. Date: Sat, 28 Jun 2003 10:37:51 -0600 To: Van Rooyen G-J [EMAIL PROTECTED] [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Re: CygWin adding CRs, hurting CVS client/server communications? I've seen the same symptoms...output is garbled because CRs are left in the strings CVS interprets, and it spits them out after concatenating them...so you wind up with lines like textCRtextNL...I've dumped the output and confirmed that this is what is happening. Another good point...I am using the CygWin CVS client, not WinCVS. Toscani At 06:49 AM 6/28/2003, you wrote: I have exactly the same problem as Toscani describes. Last week I did a routine update on my Cygwin packages, and my Cygwin CVS client (which worked fine the previous day) could not authenticate with the server any more. The login command works fine, but any subsequent operations fail to authenticate. Furthermore, the server error message is garbled, as if a CR/LF problem occurred. Client: Cygwin on WinXP Server: Redhat (not sure of the version) Authentication: Plain pserver, no SSH. Judging from Patrick's response (who uses WinCVS, and not Cygwin CVS) the problem lies somewhere in the Cygwin CVS client, not in Cygwin SSH. G-J --- in response to: --- Works like a charm here, both for binmode and textmode mounts. My system: Win2k, WinCVS and Cygwin SSH The problem mentioned in your mailing list reference was fixed long time ago. Do your line endings change as well if you scp a textfile from your client to your server? If yes, then we have indeed an ssh issue on WinXP platforms. Otherwise your problem must lie somewhere else. Patrick --- in response to: --- Hey folx...currently using OpenSSH under CygWin on an XP box to communicate with a CVS server on a Linux box. Recently upgraded my CygWin installation (1.3.22(0.78/3/2), including OpenSSH to v3.6.1p1 (the latest available under CygWin), and now CVS client/server communications over SSH (CVS_RSH=ssh) don't work. I've tracked the problem deep enough to suspect that SOMETHING in CygWin converts LF to CR+LF line terminators across SSH. This pretty much hoses CVS client/server communications, as the CVS server interprets all incoming lines as byte strings including a CR at the end (it treats LF as the actual terminator)...especially bad for pathname interpretation, but lots of other things may be affected as well. I've tried altering the CVS server code to eat the extra CRs, but too many other things break (including file data exchange I'd bet...can't tell which CRs are valid data and which are inserted by the system) for that to be effective. Found a reference in the mailing list archives to a similar problem someone was having last October, but the solution was to install a snapshot from that time period which seems to be no longer available. I'm wondering if the fix for this issue never found its way into more recent versions of the CygWin system components? I've upgraded CVS on both client and server, but based on my testing, I don't think CVS itself is adding the CRs...please flame if I'm wrong on that one. g Not sure what else to do right now but do without version control for a bit...any better ideas? - Toscani -- 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/
