Mail Archives: cygwin/1997/03/18/11:45:29
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.
>
> --
> <J Q B>
------=_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".
- Raw text -