git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Schuberth <sschuberth@gmail.com>
To: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
Cc: git@vger.kernel.org, msysgit@googlegroups.com,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Johannes Sixt <j.sixt@viscovery.net>
Subject: Re: [PATCH] Fix checkout of large files to network shares under  Windows XP
Date: Tue, 20 Apr 2010 14:42:56 +0200	[thread overview]
Message-ID: <t2xbdca99241004200542ud4e8ea5azcad918c37bcacf1a@mail.gmail.com> (raw)
In-Reply-To: <4BCCC05E.4030206@lsrfire.ath.cx>

On Mon, Apr 19, 2010 at 22:43, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:

>> +             if (written < 0 && errno == EINVAL) {
>> +                     // There seems to be a bug in the Windows XP network stack that
>> +                     // causes writes with sizes > 64 MB to fail, so we halve the size
>> +                     // until we succeed or ultimately fail.
>
> C style comments (/*...*/) are preferred over C++ style comments (//...)
> for git.

Oh well, I've changed that.

> Is there a known-good size, or at least a mostly-working one?  Would it
> make sense to start with that size instead of halving and trying until
> that size is reached?

As the comment says, the greatest size that worked in my experiments
is 64 MB, and other posts on the Internert suggest the same limit, but
it's still an unconfirmed / undocumented issue. Anyway, I'm now
starting with 64 MB right away if a write failed.

>> +                     size /= 2;
>> +             } else {
>> +                     buf += written;
>> +                     total += written;
>
> What about other errors?  You need to break out of the loop instead of
> adding -1 to buf and total, right?

Right, I've fixed that, thanks.

>> +                     if (total + size > count)
>> +                             size = count - total;
>> +             }
>> +     }
>
> Shouldn't the loop be left in the successful case, too?  write(2) is
> allowed to write less than requested, so the caller already needs to
> deal with that case anyway.

I prefer to make the wrapper as transparent as possible. If a direct
call to write would not write less than requested, the wrapper should
not either.

I've updated work/issue-409 in 4msysgit.git accordingly.

-- 
Sebastian Schuberth

  parent reply	other threads:[~2010-04-20 12:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19 12:45 [PATCH] Fix checkout of large files to network shares under Windows XP Sebastian Schuberth
2010-04-19 20:41 ` Junio C Hamano
2010-04-20  9:15   ` Johannes Schindelin
2010-04-19 20:43 ` René Scharfe
2010-04-19 22:46   ` Albert Dvornik
2010-04-20  8:18   ` Johannes Sixt
2010-04-20 12:42   ` Sebastian Schuberth [this message]
2010-04-20 12:57     ` Johannes Sixt
2010-04-20 14:21       ` Sebastian Schuberth
2010-04-20 20:49     ` René Scharfe
2010-04-29 20:01       ` René Scharfe
2010-04-30  8:46         ` Johannes Sixt
2010-04-30  9:08         ` Sebastian Schuberth
     [not found]         ` <290b11b5-5dd5-4b83-a6f5-217797ebd5af@t8g2000yqk.googlegroups.com>
2010-10-16 17:23           ` René Scharfe
2010-10-17 10:54             ` Dmitry Potapov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=t2xbdca99241004200542ud4e8ea5azcad918c37bcacf1a@mail.gmail.com \
    --to=sschuberth@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=j.sixt@viscovery.net \
    --cc=msysgit@googlegroups.com \
    --cc=rene.scharfe@lsrfire.ath.cx \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).