Hi,
just re-tested this with cygwin1-20110313.dll.
Here is the result (output of my "writetest" program):
writing 78954543 bytes...
result is 32505856, errno is 27
writing 46448687 bytes...
result is -1, errno is 27
writing 46448687 bytes...
result is -1, errno is 27
[ repeating a few hundred ti
How about if you try a snapshot rather than your own home-built
version?
There is no snapshot dated 03-10 on http://cygwin.com/snapshots/.
Unfortunately, there is no "hard limit" of 64MB.
On the machine where I first encountered the error, the limit seems to
be about 16MB. On another machine,
On Thu, Mar 10, 2011 at 04:11:41PM -0500, Christopher Faylor wrote:
>On Thu, Mar 10, 2011 at 09:11:52PM +0100, Robert Wruck wrote:
>>Hi,
>>
>>tested with cvs HEAD:
>>
>>> Just terminating the loop after write_overlapped_fallback is not enough.
>>> When the size to write exceeds MAX_OVERLAPPED_WRITE
On Thu, Mar 10, 2011 at 09:11:52PM +0100, Robert Wruck wrote:
>Hi,
>
>tested with cvs HEAD:
>
>> Just terminating the loop after write_overlapped_fallback is not enough.
>> When the size to write exceeds MAX_OVERLAPPED_WRITE_LEN and WriteFile
>> fails for MAX_OVERLAPPED_WRITE_LEN, write() will alwa
Hi,
tested with cvs HEAD:
Just terminating the loop after write_overlapped_fallback is not enough.
When the size to write exceeds MAX_OVERLAPPED_WRITE_LEN and WriteFile
fails for MAX_OVERLAPPED_WRITE_LEN, write() will always return 0.
Now any write with length > MAX_OVERLAPPED_WRITE_LEN fails
On Wed, Mar 09, 2011 at 08:46:43PM +0100, Robert Wruck wrote:
>>> I replaced the cygwin1.dll with cygwin1-20110309.dll and now a single
>>> write() with 78 MB never returns but seems to write repeatedly to the
>>> pipe (file was 5GB when I hit Ctrl-C).
>
>Just terminating the loop after write_overl
I replaced the cygwin1.dll with cygwin1-20110309.dll and now a single
write() with 78 MB never returns but seems to write repeatedly to the
pipe (file was 5GB when I hit Ctrl-C).
Just terminating the loop after write_overlapped_fallback is not enough.
When the size to write exceeds MAX_OVERLAPPE
I replaced the cygwin1.dll with cygwin1-20110309.dll and now a single
write() with 78 MB never returns but seems to write repeatedly to the
pipe (file was 5GB when I hit Ctrl-C).
... you don't want to keep_looping after calling
write_overlapped_fallback ...
--
Problem reports: http://cy
> I've just uploaded a snapshot which attempts to work around this
> problem. I ended up making some fairly substantial changes to the
> pipe handling so this needs some serious testing, especially on
> different platforms, e.g., XP, XP64, Windows 2008, etc.
Oops..
I replaced the cygwin1.dll wi
Surprisingly, this returns FALSE / nbytes = 0 / GetLastError =
ERROR_INVALID_HANDLE on WinXP if the number of bytes exceeds some
maximum and the handle refers to a pipe.
Since you don't know what kind of handle you're writing to in
write_overlapped, it seems reasonable to do the write in chunks.
On 3/9/2011 1:24 PM, Robert Wruck wrote:
Hi,
Hang on, you are saying that a *blocking* write(2) to a pipe returns
with EAGAIN? Are you sure? It would be quite a surprise if git would
actually do that. EAGAIN is only an expected error for non-blocking
I/O, so applications which use blocking I/O
On Wed, Mar 09, 2011 at 07:24:11PM +0100, Robert Wruck wrote:
>On Mon, Mar 07, 2011 at 11:39:51AM +0100, Corinna Vinschen wrote
>>Hang on, you are saying that a *blocking* write(2) to a pipe returns
>>with EAGAIN? Are you sure? It would be quite a surprise if git would
>>actually do that. EAGAIN
Hi,
Hang on, you are saying that a *blocking* write(2) to a pipe returns
with EAGAIN? Are you sure? It would be quite a surprise if git would
actually do that. EAGAIN is only an expected error for non-blocking
I/O, so applications which use blocking I/O usually only test for EINTR.
I checke
On Mon, Mar 07, 2011 at 11:38:49AM -0500, Christopher Faylor wrote:
>On Mon, Mar 07, 2011 at 10:37:08AM -0500, Christopher Faylor wrote:
>>On Mon, Mar 07, 2011 at 11:39:51AM +0100, Corinna Vinschen wrote:
>>>On Mar 5 21:12, Robert Wruck wrote:
Hi,
recently, I found that cygwin-git
On Mon, Mar 07, 2011 at 10:37:08AM -0500, Christopher Faylor wrote:
>On Mon, Mar 07, 2011 at 11:39:51AM +0100, Corinna Vinschen wrote:
>>On Mar 5 21:12, Robert Wruck wrote:
>>> Hi,
>>>
>>> recently, I found that cygwin-git was not able to 'cat-file' files
>>> that exceeded some size (in my case a
On Mon, Mar 07, 2011 at 11:39:51AM +0100, Corinna Vinschen wrote:
>On Mar 5 21:12, Robert Wruck wrote:
>> Hi,
>>
>> recently, I found that cygwin-git was not able to 'cat-file' files
>> that exceeded some size (in my case about 80MB).
>> I tracked this down to the cygwin implementation of write()
Hi,
Hang on, you are saying that a *blocking* write(2) to a pipe returns
with EAGAIN? Are you sure? It would be quite a surprise if git would
actually do that. EAGAIN is only an expected error for non-blocking
I/O, so applications which use blocking I/O usually only test for EINTR.
since in
On Mar 5 21:12, Robert Wruck wrote:
> Hi,
>
> recently, I found that cygwin-git was not able to 'cat-file' files
> that exceeded some size (in my case about 80MB).
> I tracked this down to the cygwin implementation of write() that
> behaves quite odd in some cases.
>
> I wrote a small program (s
Hi,
recently, I found that cygwin-git was not able to 'cat-file' files that
exceeded some size (in my case about 80MB).
I tracked this down to the cygwin implementation of write() that behaves
quite odd in some cases.
I wrote a small program (source attached) that mmaps a given file and
trie
19 matches
Mail list logo
