Problems with new ci.exe and co.exe

Problems with new ci.exe and co.exe

[Tolkin, Steve]

A while ago I asked in this mailing list (cygwin@sourceware.cygnus.com)
if there was a new version of the rcs utilities.  
The reason I asked is that when I ran my old ci.exe in a bash window it
hung.  
I could run it successfully in emacs though.  
To cause the problem in bash just say e.g.
  ci foo
After pressing control-C to break out I also had delete the lock file
that ci had created.  
For example in a bash shell ci -l foo created a lock file named RCS/fo_

In response Uwe Steinfeld sent me new versions of ci.exe and co.exe.
However after using the new ci.exe and the new co.exe for a while I
encountered
a variety of problems.  
The most serious one is that sometimes after doing a ci and then a co
the file would be totally corrupted!

I still do not understand exactly what caused this.
But I have a theory that it is related to the handling of newlines.

The old rcs utilities followed the rule that the RCS file 
always has Unix style newlines, i.e. just \n.  
The work file has "native" newlines, which on DOS and Windows 
means the \r\n pair.
However the following transcript shows that the new ci.exe 
and co.exe do not follow this rule.  One consequence is that 
immediately after checking a file in running rcsdiff will 
show every line to be different.  This is clearly wrong.

I show the contents of files using od -c (Be warned that other
utilities, have various quirks about files that only differ in
their newlines, e.g. diff can say they are the same.)

606~/n> cat testrcs
hello
world
607~/n> od -c testrcs
0000000   h   e   l   l   o  \r  \n   w   o   r   l   d  \r  \n
0000016
608~/n> md5sum /_otherbin/NEW_RCS_UTIL/ci.exe
904cf82aec3c489f0f5d89576d394f55  /_otherbin/NEW_RCS_UTIL/ci.exe
609~/n> ls -l /_otherbin/NEW_RCS_UTIL/ci.exe
-rwxr-xr-x   1 administ Administ    72192 Jun  2 14:15
/_otherbin/NEW_RCS_UTIL/c
i.exe*
610~/n> type ci
ci is aliased to `/_otherbin/NEW_RCS_UTIL/ci.exe'
611~/n> ci -l testrcs
RCS/testrcs  <--  testrcs
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> .
initial revision: 1.1
done
612~/n> od -c RCS/testrcs
0000000   h   e   a   d  \t   1   .   1   ;  \n   a   c   c   e   s   s
0000020   ;  \n   s   y   m   b   o   l   s   ;  \n   l   o   c   k   s
0000040  \n  \t   S   Y   7   1   0   4   6   :   1   .   1   ;       s
0000060   t   r   i   c   t   ;  \n   c   o   m   m   e   n   t  \t   @
0000100   #       @   ;  \n  \n  \n   1   .   1  \n   d   a   t   e  \t
0000120   2   0   0   0   .   0   6   .   1   4   .   2   1   .   5   7
0000140   .   5   9   ;  \t   a   u   t   h   o   r       S   Y   7   1
0000160   0   4   6   ;  \t   s   t   a   t   e       E   x   p   ;  \n
0000200   b   r   a   n   c   h   e   s   ;  \n   n   e   x   t  \t   ;
0000220  \n  \n  \n   d   e   s   c  \n   @   @  \n  \n  \n   1   .   1
0000240  \n   l   o   g  \n   @   I   n   i   t   i   a   l       r   e
0000260   v   i   s   i   o   n  \n   @  \n   t   e   x   t  \n   @   h
0000300   e   l   l   o  \r  \n   w   o   r   l   d  \r  \n   @  \n
0000317
613~/n> rcsdiff testrcs
===================================================================
RCS file: RCS/testrcs
retrieving revision 1.1
diff -r1.1 testrcs
1,2c1,2
< hello
< world
---
> hello
> world


But wait, there's more.
In the example above I created a new file using the new ci.exe.
But most of my files were created a long time ago, with the old ci.exe.
When I run the old co.exe on them they have the native \r\n newlines
as desired.  But when I run the new co.exe they have the Unix style
newlines.
I think this is also wrong.

627~/w> mv do do_keep
628~/w> /_otherbin/NEW_RCS_UTIL/co do
RCS/do  -->  do
revision 1.227
done
629~/w> od -c do | head -6
0000000   T   h   i   s       f   i   l   e       i   s       ~   /   w
0000020   /   d   o                                       -   *   -   t
0000040   e   x   t   -   *   -       u   s   e   d       b   y       E
0000060   m   a   c   s  \n   W   r   i   t   t   e   n       b   y
0000100   S   t   e   v   e       T   o   l   k   i   n  \n   T   i   m
0000120   e   -   s   t   a   m   p   :       <   2   0   0   0   -   0
630~/w> rm do
rm: remove `do', overriding mode 0444? y
631~/w> /_otherbin/ORIG_RCS_UTIL/co do
RCS/do  -->  do
revision 1.227
done
632~/w> od -c do | head -6
0000000   T   h   i   s       f   i   l   e       i   s       ~   /   w
0000020   /   d   o                                       -   *   -   t
0000040   e   x   t   -   *   -       u   s   e   d       b   y       E
0000060   m   a   c   s  \r  \n   W   r   i   t   t   e   n       b   y
0000100       S   t   e   v   e       T   o   l   k   i   n  \r  \n   T
0000120   i   m   e   -   s   t   a   m   p   :       <   2   0   0   0

I got my old versions of ci.exe and co.exe from some Gnu binary site.
I am not even sure exactly where anymore.  But they were part of a group
of files called RCS 5.7.  This should permit someone to determine exactly 
their origin.

633~/w> md5sum /_otherbin/ORIG_RCS_UTIL/co.exe
e7e62470f560d26ba0338d46af3bf3c2  /_otherbin/ORIG_RCS_UTIL/co.exe
634~/w> md5sum /_otherbin/ORIG_RCS_UTIL/ci.exe
0b838d96de55d19dd5942942eec8fc32  /_otherbin/ORIG_RCS_UTIL/ci.exe

I do not have the source for these, but kind of wish I did.
Then perhaps I could just apply Uwe's patch referred to below,
and might be all set.

For completeness I am including directly below this the email 
I sent to Uwe earlier, and below that his response.
These contain some useful additional information.

////////////////////////////////////////////////////////////////////////////
/

Dear Uwe,
	Thank you for sending me these files.  

Unfortuantely I suspect the new co.exe somehow has a role in corrupting my
files.  
I made some change in emacs, and then invoked its check in command.
This calls ci to do the work.
I had been using this successfully with the standard version 5.7 of ci for
about a year.
After the check in I noticed that only the first 30 lines (out of 491)
survived! 
It had truncated (discarded) all the rest.
Needless to say I was worried.  Then, when I went to
the shell to check out the previous version, I got the error message from co
"edit script refers to line past end of file"
Now I was really worried. 
To help diagnose the problem I made a copy of the RCS file which I renamed
to old_bad_genxml1.pl

Here are some additional details.

I noticed that your new versions have a hard coded path, i.e. they expect
the program to be in /usr/bin.  I had installed them in c:\_otherbin
which was on my path.   So emacs was able to find co, and it was able to
find rcsdiff, but then I think rcsdiff failed because it looked for
/usr/bin/co

I do not think this is related to the truncation problem, but it *is* a
problem.

Below see that rlog reported the most recent change had deleted all the
lines in the file and added an equal number.  When I see this I sometimes
suspect a newline problem between Unix and DOS.  But this file had always
been on DOS.

649/_mybin> rlog old_bad_genxml1.pl |head -22

RCS file: RCS/old_bad_genxml1.pl
Working file: old_bad_genxml1.pl
head: 1.19
branch:
locks: strict
        SY71046: 1.19
access list:
symbolic names:
keyword substitution: kv
total revisions: 19;    selected revisions: 19
description:
----------------------------
revision 1.19   locked by: SY71046;
date: 2000/06/05 15:53:57;  author: SY71046;  state: Exp;  lines: +491 -491
*** empty log message ***
----------------------------
revision 1.18
date: 2000/04/14 18:45:45;  author: SY71046;  state: Exp;  lines: +13 -7
*** empty log message ***
----------------------------
revision 1.17
...

The good news is that I was able to recover the file (I believe) by going
into the RCS file and extracting the whole section that it had from the
earlier version, making a new work file, and checking in that file.  But
then the same problem happended again, to a different file, this time
truncating everything after line 23.  So I decided to go back to the older
version of co.exe and with it the older version of ci.exe.

Have you seen something like this?  
I can mail you the corrupted RCS file in case this would provide a clue as
to what went wrong.

Also, I am now noticing many 0 byte files with names like _1000269 _1000317
etc.
in the work directory.
Are these written by one of your programs?  They do not seem to get cleaned
up automatically.  They are in group None.

Some good news is that I was able to check in files.
As you said I need to set RCSINIT=-x
But in order for this to work I also I needed to do some other changes;
the new code and that setting were not enough.  I think the key additional
change was saying:
chgrp Administrators /temp
(Before that the group for /temp was either None or System.)

However I do not want to use your new ci.exe with my old co.exe, because of
the risks of version skew.

Steve

> -----Original Message-----
> From: Uwe H. Steinfeld [ mailto:usteinfeld@nikocity.de ]
> Sent: Friday, June 02, 2000 7:52 AM
> To: Tolkin, Steve
> Subject: Re: rcs ci fails under cygwin; ci foo hangs leaving 
> a lock file
> RCS/fo_
> 
> 
> > I tried this, but it did not help.  Any other ideas?
> > 
> > Thanks,
> > Steve
> 
> Check my ChangeLog and patch file, attached.
> Otherwise I could send my binaries (compiled with this patch 
> under cygwin).
> They still need RCSINIT=-x
> 
> Uwe
> 
> 

Uwe reponded:

> -----Original Message-----
> From: Uwe H. Steinfeld [ mailto:usteinfeld@nikocity.de ]
> Sent: Wednesday, June 07, 2000 12:41 PM
> To: Tolkin, Steve
> Subject: Re: Problems, possibly with your new ci.exe and co.exe
> 
...
> 
> > I noticed that your new versions have a hard coded path, ...
> 
> Indeed, it's configured with "--with-diffutils", and I can 
> see that diff and
> diff3 are hardcoded.
> BTW, all that I changed in the GNU sources is the patch I 
> already sent you.
> And as I remember now the main problem was the "write access" 
> which caused
> the problems for me with ci giving similar result as you got.
> 
> > Also, I am now noticing many 0 byte files with names like _1000269
> _1000317
> > etc. in the work directory.
> > Are these written by one of your programs?
> 
> At least not explicitly. They look like temp files (using a 
> PID or by some
> mktemp).
> I could well imagine that it is related to your /tmp problems 
> as I see from
> your other posts to the group
> > (cpp.exe: /tmp/ccQh4PLx.i: Permission denied)
> I know that I had similar problems when I started with Cygwin.
> I cannot remember the exact solution but I thing it was with the old
> binary/text mount feature and went away when I consequently 
> used binary
> mounts and installed the binary in c:\bin and c:\usr\bin, 
> mounted as /bin
> and /usr/bin resp.
> 
> Sorry, but I think I'm not that much help for you
> Uwe
 

Hopefully helpfully yours,
Steve
-- 
Steven Tolkin          steve.tolkin@fmr.com      617-563-0516 
Fidelity Investments   82 Devonshire St. R24D    Boston MA 02109
There is nothing so practical as a good theory.  Comments are by me, 
not Fidelity Investments, its subsidiaries or affiliates.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Problems with new ci.exe and co.exe

[Christopher Faylor]

On Fri, Jun 16, 2000 at 10:27:21AM -0400, Tolkin, Steve wrote:
>Dear group, especially Rod W., Chris F., and Uwe S. (who will get this as
>direct email as well as via the list)

There is no reason to send me email directly.  I obviously read the
cygwin mailing list.  I don't need to have duplicates in my mailbox.

>Uwe avoided that bug becase he mounted everything as binmode.
>But I had to mount c: as textmode to work around a "Permission denied"
>problem I got when running gcc (which invoked cpp), rcsdiff (which invoked
>co and diff), and sort.

As I have previously indicated, I have never heard of anyone solving a
"permission denied" error by changing to text mode.

>I generally try to minimize the disturbances to me system.  But here I can
>change up to four independent variables.  I would like your collective
>advice about this.
>Here are the possibilities:
>1. Change from release 1.1.1 to 1.1.2.  I plan to do this, but first I would
>like to see the detailed description of the line endings bug above.

Read ChangeLog entries for newlib for a detailed description or go
through a few weeks worth of cygwin mailing list where people were
complaining about the problem.

As the announcement said, it fixes problems with not translating CRLF
line endings correctly.  If you are having problems with CRLF line
endings showing up in your files then I have a hard time understanding
why you would go to the effort of composing a long email message rather
than updating your DLL.  Backup your directories if you think that
updating will have a catastrophic effect.

>2. Change from textmode to binmode for C:/  I may try this, to see if I am
>still getting "Permission denied".  But even if that problem is gone it
>seems strange to mount this binmode when many of the files on that drive are
>text.  Someone also mentionned that it seemed very odd that I had e.g.
>/usr/bin mounted in binmode but that / was textcode

There is nothing wrong with mounting / as text mode assuming that you
understand what you're doing.

>3. Change the root of the cygwin installation from C:/ to C:/cygwin   
>I originally chose to install cygwin into the root directory i.e.  c:/
>Later I read somewhere that this is not recommended, and it recommended
>installing into e.g.  c:/cygwin.  But it did not give the reasons, or
>the pros and cons of each.  I will change this if someone can explain
>to me why I should.

Again, the mailing list archives are your friend.

If you don't want to install in c:\cygwin there is no reason why you should
have to.  Basically, it just encapsulates all of the cygwin stuff in one
directory.

>4. Change from the original ci.exe and co.exe I have been running to the new
>versions provided by Uwe. (Later maybe can also try to compile them  myself,
>and then apply the patches and compile again).
>
>An important extra question:  Currently my $HOME is /usr/home and I have a
>lot of files there.  I am concerned that a new install might somehow damage
>(i.e. remove) things below /usr.  Should I for safety's sake do something
>like
>mv /usr/home /_myhome
>HOME=/_myhome

For safety's sake, if you are concerned about losing things, you should backup
your files and not rely on supposition from people in a mailing list.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Problems with new ci.exe and co.exe

[Tolkin, Steve]

Dear group, especially Rod W., Chris F., and Uwe S. (who will get this as
direct email as well as via the list)
	Immediately below is a snippet from the release notice at
http://sourceware.cygnus.com/ml/cygwin-announce/2000/msg00023.html .  
Is there a way for me to get more details about this bug. 
- Fixed problems with \r\n line endings manifesting when text mode
  was specified.

Uwe avoided that bug becase he mounted everything as binmode.
But I had to mount c: as textmode to work around a "Permission denied"
problem I got when running gcc (which invoked cpp), rcsdiff (which invoked
co and diff), and sort.

I generally try to minimize the disturbances to me system.  But here I can
change up to four independent variables.  I would like your collective
advice about this.
Here are the possibilities:
1. Change from release 1.1.1 to 1.1.2.  I plan to do this, but first I would
like to see the detailed description of the line endings bug above.
2. Change from textmode to binmode for C:/  I may try this, to see if I am
still getting "Permission denied".  But even if that problem is gone it
seems strange to mount this binmode when many of the files on that drive are
text.  Someone also mentionned that it seemed very odd that I had e.g.
/usr/bin mounted in binmode but that / was textcode
3. Change the root of the cygwin installation from C:/ to C:/cygwin   
I originally chose to install cygwin into the root directory i.e. c:/
Later I read somewhere that this is not recommended, and it recommended
installing into e.g. c:/cygwin.  But it did not give the reasons, or the
pros and cons of each.  
I will change this if someone can explain to me why I should.
4. Change from the original ci.exe and co.exe I have been running to the new
versions provided by Uwe. (Later maybe can also try to compile them  myself,
and then apply the patches and compile again).

An important extra question:  Currently my $HOME is /usr/home and I have a
lot of files there.  I am concerned that a new install might somehow damage
(i.e. remove) things below /usr.  Should I for safety's sake do something
like
mv /usr/home /_myhome
HOME=/_myhome

My current mounts are
Device              Directory           Type         Flags
C:\bin              /usr/bin            user         binmode
C:\lib              /usr/lib            user         binmode
d:                  /d                  user         textmode
f:                  /f                  user         textmode
c:                  /                   user         textmode
e:                  /e                  user         textmode

Many thanks, 

Steve

> -----Original Message-----
> From: Rod Whitby [ mailto:rwhitby@asc.corp.mot.com ]
> Sent: Thursday, June 15, 2000 7:55 PM
> To: Tolkin, Steve
> Cc: 'Uwe H. Steinfeld'
> Subject: Re: Problems with new ci.exe and co.exe
> 
> 
> "Tolkin, Steve" wrote:
> > What version of cygwin are you running?  I am on 1.1.1
> > and I have seen an announcement for 1.1.2, so I might try 
> upgrading to that.
> 
> That could be the problem - 1.1.1 has a bug to do with end of line
> handling.  You should upgrade to 1.1.2 immediately.  That fixed my
> Makefile problems.
> 
> Here's the diff I used to compile rcs-5.7 from the official 
> FSF sources.
> 
> Rod
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com