I tried the same thing on my UNIX machine to see what the difference might be, and I couldn't come up with anything. So, keep a few things in mind about Windows (partially OT, as it's more process maintenance and windowsism from this point on, but in this case, one may need to think outside the shebang):

• (early) Windows may lose file handles on files larger than Two Gigs (or four on NT 4 systems). The OS simply can't handle them, so keep that in mind. Windows 95 can only have 65535 handles accessed at one. If you have a lot of stuff running, a few programs open like this, and it may not reclaim them.
• Depending on your partition type, and how /foo/ comes up, it may be possible to read the maximum amount of files in a directory (there is a limit, albeit high). This can be a really stray error, but heck, it's 4 gigs of text.
• Windows may think that you are a process out of control, and may attempt to stop you. A sleep(10) or even something as small to let Windows know you are resting might be good. I don't know how far Windows NT will let you spin before doing something about it. There is a limit to it however. I don't know why it would dirty your file handles however.
• Your file may very well be damaged. If there is a bit of binary data, or your file size is misrepresented, then you could quite possibly be returning EOF before it's time. Scandisk... I'm serious. A 4 gig file is a lot to keep together.
• Make sure your file handle isn't dying. Is this a local or network file? Around what does it die? The regexp is really simple, but maybe there is something glaring I'm over looking. Without more details, I can give is a set of vague guesses. Same place every time?

Here is the code I used, you may wish to do the same:

#!/usr/bin/perl -w

use strict;

my $n=0;open(OUT,">$n.out");
while(<>) {
    print OUT or die "Lost file handle\n";
    if (/foo/) {close(OUT);$n++;open(OUT,">$n.out") or die "Can't
get file handle\n";}
}
print "Reached EOF\n";
close(OUT);
[download]

I used some web logs to test it, and it was fine. No huge memory consumption (and these are big logs), just did what it was supposed to do. If you are using Windows 2000 or NT, load up the process viewer and add in a file handles view, to make sure it isn't leaking them. Try the sleep(). Who knows, being a better OS citizen may actually work.

Good luck.