Hi friends

I've been mailing back and forth with Orna Haber, who filed bug report
#994165:
http://sourceforge.net/tracker/index.php?func=detail&aid=994165&group_id=976&atid=100976

He has attached source files that both show how to repeat the problem as well
as his suggested fix for it.

Since this is on Windows, I need input from people with Windows knowledge.

It is apparently a case where fwrite() returns an error, but if the fwrite()
is retried, it succeeds!

Is this a bug in Windows' fwrite()-implementation we need to work-around?

(The mail below is forwarded with permission.)

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html
---------- Forwarded message ----------
Date: Wed, 28 Jul 2004 15:31:36 -0400
From: "Haber, Orna"
Subject: RE: curl bug #994165
1. You wrote:
" Yes I know and that's why I asked you. How can this happen?"
>> I sent you a source files that describe test steps to reproduce the
failure if you really want to study HOW CAN THIS HAPPEN as I don't know
the answer to this question.
What I do know is that despite the failure to write, if I try to write
the remaining buffer to Http server, on the second write, it will
succeed and the file that I am trying to write will not be corrupt which
means that my wish for today has just been fulfilled...
" The fwrite() function returns the number of members successfully
written,
      which may be less than nitems if a write error is encountered.
... so, if it is less than the number passed in, it is a failure."
My reply>> That's right, libcurl returns a Write-error due to 'wrote' <
'len' BUT because there is no good reason for failure, I made a retry
for the remaining buffer. Good reasons for failure could be any of the
following:
1. The channel of communication dropped dead and couldn't be
re-established. (No, this is not the case)
2. Insufficient disk-space (No, this is not the problem)
2. You wrote: " That is an ugly work-around that shouldn't be necessary
and again: that's why
I asked you how you can make fwrite() return a bad value."
Your conclusion: " Until you can convince me that this behavior is
normal and expected on
Windows, I won't do anything about it but only consider it a peculiar
Windows
bug. The code uses fwrite() as fwrite() is documented to work.
Please take this discussion to the libcurl mailing list with further
details
if you still disagree with me. I don't know much about Windows or
Windows
internals."
My reply>> This behavior is not normal and it could be that someone who
is expert in Windows internals might have a look at this bug before you
throw it to the dust-bin and this expert might come up with a much
better solution than the patch that I wrote in sendf.c. I would like to
suggest that you forward this bug description to a Windows expert as I
do not intend to pursue justice by taking it further to libcurl mailing
list.
I will be happy to co-operate with a Windows expert (or anyone) who
starts studying the test source files that I sent and needs further
assistance at reproducing the bug in order to solve it better than the
ugly path that I wrote.
Despite disagreeing with you I would like to thank you for your mail.
It indicates that you were interested in looking into this problem.
Orna Haber
-----Original Message-----
From: Daniel Stenberg [mailto:daniel_at_haxx.se]
Sent: Wednesday, July 28, 2004 11:53 AM
To: Haber, Orna
Subject: RE: curl bug #994165
On Mon, 26 Jul 2004, Haber, Orna wrote:
> 2. fwrite() should never return anything by the same amount as given
to it,
> as everything else is a failure. Can you explain why fwrite() fails
for you
> in this case
>
> As the title of the bug suggests: I don't see a good reason for
fwrite() to
> return 'wrote' < 'len' and fail.
Yes I know and that's why I asked you. How can this happen?
(quote from the Single UNIX (r) Specification, Version 2 for fwrite:)
   RETURN VALUE
      The fwrite() function returns the number of members successfully
written,
      which may be less than nitems if a write error is encountered.
... so, if it is less than the number passed in, it is a failure.
> In the bug, I attached a zip file that includes sendf.c with a
proposed
> solution (patch): All the patch does it to fwrite() the remaining
bytes to
> the server, which makes sure that the complete buffer is written
> successfully.
That is an ugly work-around that shouldn't be necessary and again:
that's why
I asked you how you can make fwrite() return a bad value.
> Please note that it always fails on writing a header (type of) info to
the
> server and it happens on the 9th file written to the server.
Until you can convince me that this behavior is normal and expected on
Windows, I won't do anything about it but only consider it a peculiar
Windows
bug. The code uses fwrite() as fwrite() is documented to work.
Please take this discussion to the libcurl mailing list with further
details
if you still disagree with me. I don't know much about Windows or
Windows
internals.
--
           -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
    ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol