#19886 [Fbk->Opn]: readfile, fread, fpassthru won't work with large files!!!

From: Date: Tue, 29 Oct 2002 22:14:28 +0000
Subject: #19886 [Fbk->Opn]: readfile, fread, fpassthru won't work with large files!!!
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-23656@lists.php.net to get a copy of this message
 ID:               19886
 Updated by:       spic@php.net
 Reported By:      spic@php.net
-Status:           Feedback
+Status:           Open
 Bug Type:         Filesystem function related
 Operating System: Windows, any Version
 PHP Version:      4CVS-2002-10-13
 New Comment:

For me, I dont have output buffering or ob_gzhandler,
or zlib.output_compression or transparent SID/session rewriting
enabled. I tested even a max execution time of a day.


Previous Comments:
------------------------------------------------------------------------

[2002-10-29 09:10:49] wez@php.net

As a sanity check, you're not using output buffering or ob_gzhandler,
or zlib.output_compression or transparent
SID/session rewriting, are you?

------------------------------------------------------------------------

[2002-10-29 06:55:29] selfman@lasercat.de

I have a simmilar problem on windows 2000 Server with IIS4.
I use this script (just a part):
header("Content-type: Download");
header("Content-Disposition: attachment;
filename=".$Data->SWFileName);
$fp = fopen ($GLOBALS['FileLocation'].$Data->SWFileName, "rb");
fpassthru($fp);

The problem is that on our development machine (Linux) everything works
like a charm, but on our "Production" server with Win2k Server & IIS
not.
There is a small JavaScript which calls the file sending script usimg
window.location='getfile.php?fileid=56'

The problem place is that the time between request and displaying the
"save" dialog is very large. (1-2 minutes or so) I can't get it to
execute faster.
I will try to use the fread().

Later

SelfMan

------------------------------------------------------------------------

[2002-10-13 19:06:50] wez@php.net

I just fixed (I hope) a socket-shutdown bug (#16114).
The interesting thing is that this is only to do with
writes to sockets opened by streams (so it should not
affect PHP output).

It might be that the Microweb server also has a similar
bug, or that it has some other threading issue.

It doesn't make sense for this to be related solely to
streams, as they aren't time-dependent, and they are
certainly not dependent on other PHP processes.

Can you try reproducing the problem using Apache, PWS
or IIS?
Can anyone reproduce this on another platform?


------------------------------------------------------------------------

[2002-10-13 17:21:54] sniper@php.net

Did this work in any previous versions of PHP?
Is it stricly win32 thing? Does this workin in e.g. Linux?


------------------------------------------------------------------------

[2002-10-13 10:40:41] nicos@php.net

May be its because that the stream hasn't enough time to get its new
position. I didn't read streams.c/h well enough too.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/19886

-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1



Thread (21 messages)

« previous php.bugs (#23656) next »