Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Message-ID: From: "Tolkin, Steve" To: cygwin AT sourceware DOT cygnus DOT com, "'Uwe H. Steinfeld'" Subject: Problems with new ci.exe and co.exe Date: Wed, 14 Jun 2000 18:34:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" A while ago I asked in this mailing list (cygwin AT sourceware DOT cygnus DOT 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 AT nikocity DOT 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 AT nikocity DOT 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 DOT tolkin AT fmr DOT 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 AT sourceware DOT cygnus DOT com