From: jeffdb AT netzone DOT com ("Mikey") Subject: Re: Patch for reliable rcs on win95 18 Mar 1997 11:45:29 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199703181622.JAA04349.cygnus.gnu-win32@nz1.netzone.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01BC337A.8FD8AD60" Content-Transfer-Encoding: 7bit Original-To: "Jim Balter" Original-Cc: "cygnus" X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Original-Sender: owner-gnu-win32 AT cygnus DOT com This is a multi-part message in MIME format. ------=_NextPart_000_01BC337A.8FD8AD60 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jim I think it's fast_copy in rcsutil, that exibits this behavior in rcs, ignoring the size of the returned read. under linux you either get what you asked for, EOF or an error, and some programs count on this behavior including rcs. To see an example do ci -u filename rcs -U filename make some changes to the file export strace=1,strace.log and use rcs configured as default (without large_memory) to do ci -u filename when you read through the strace.log file, you should see something like read (3, 0x4683004, 1024) 1024=read(3, 0x4683004, 1024) write (4, 0x4683004, 1024) 1024 = write(4, 0x4683004, 1024) read (3, 0x4683004, 1024) 921 = read(3, 0x4683004, 1024) << short read write (4, 0x4683004, 1024) << ignored This will give you a truncated RCS/filename,v Out of the 20 plus files in the winsup directory 2 did this consistently for me VERY ANNOYING!! It dosen't happen all the time, and maybe it's just my system, but based on what Ron says (following) I don't think so. One thing I have seen: file i/o does not always works as it does on unix. For example, reading from a file, 1024 bytes at a time, with a file of 65536 bytes, will get me return values of: 1023, 1021, 1015, etc. Almost always 1024, but enough of these oddballs to cause trouble for programs that don't carefully check return values from read() (there are some of these ...). I had to fix the rtsp ref. port from realaudio to accomodate this strange read(2) behavior. ron Ron Minnich |"Failure is not an option" -- Gene Kranz rminnich AT sarnoff DOT com | -- except, of course, on Microsoft products (609)-734-3120 | ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html I was kind of tired last night, so I forgot to insert the diff, and since I don't see my second message this morning I'll include it here again. (sorry if you got it twice). > Mikey wrote: > > > The win95 short read bug also affects rcs ci co & company (at least for > > me). > > Hi. What bug is this? Is it written up somewhere? Thanks. > > > cd into the rcs-5.7/src directory and apply the included dif. > > Um, what included dif? There wasn't one with the message I received. > > -- > ------=_NextPart_000_01BC337A.8FD8AD60 Content-Type: application/octet-stream; name="conf_sh.dif" Content-Transfer-Encoding: quoted-printable Content-Description: conf_sh.dif (DIF File) Content-Disposition: attachment; filename="conf_sh.dif" --- conf.sh.orig Mon Mar 17 18:15:23 1997=0A= +++ conf.sh Mon Mar 17 18:22:37 1997=0A= @@ -1794,8 +1794,8 @@=0A= EOF=0A= $PREPARE_CC || exit=0A= h=3D0 p=3D0=0A= -if ($CL a.c $L && sh -c 'pid=3D$$; (sleep 3; kill $pid)& exec '$aout) = >&2=0A= -then=0A= +if ($CL a.c $L && sh -c 'pid=3D$$; (sleep 3; kill $pid)& sleep 4;exec = '$aout) >&2=0A= +then #extra sleep for fork bug=0A= h=3D1=0A= $PREPARE_CC || exit=0A= $CS -Dhas_attribute_format_printf=3D1 a.c >&2 && $CS_OK && p=3D1=0A= @@ -1890,10 +1890,11 @@=0A= echo "$a#undef EXIT_FAILURE $z/* Uncomment this if EXIT_FAILURE is = broken. */"=0A= =0A= : configuring large_memory=0A= -case "$has_map_fd$has_mmap" in=0A= -*1*) l=3D1;;=0A= -*) l=3D0=0A= -esac=0A= +#case "$has_map_fd$has_mmap" in=0A= +#*1*) l=3D1;;=0A= +#*) l=3D0=0A= +#esac=0A= +l=3D1 #force large_memory to overcome win95 short read bug=0A= echo "#define large_memory $l /* Can main memory hold entire RCS files? = */"=0A= =0A= $ech >&3 "$0: configuring LONG_MAX $dots"=0A= ------=_NextPart_000_01BC337A.8FD8AD60-- - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".