This is the mail archive of the cygwin@sourceware.cygnus.com 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]

Problems with new ci.exe and co.exe


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


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