From: moptop69 at ntlworld dot com
Operating system: Win2k Pro Sp3
PHP version: 4.3.1
PHP Bug Type: Filesystem function related
Bug description: possible problem with fseek/fread under ISAPI on IIS5
okay, i've recently come accross a problem on Win2k, after a hardrive
crash, i installed the latest PHP release (4.3.0) and tried to run a
script that mainly consists of parsing a Python 'pickled' output file into
a MySql table format.
Mostly its a continuous fread from start to finish, but in certain areas,
i have to check the next byte in the file using this code:
function gtnxt(&$my2ndFnFile, &$i)
{
// fseek($my2ndFnFile, $i);
$data=fread($my2ndFnFile,1);
fseek($my2ndFnFile, $i);
$d0=ord($data[0]);
return $d0;
}
and read the byte again after ive checked its byte value with:
function gt_8(&$my2ndFnFile, &$i)
{
// fseek($my2ndFnFile, $i);
$data=fread($my2ndFnFile,1);
$i+=1;
$d0=ord($data[0]);
return $d0;
}
the first variable in both functions is the file handle (opened with "rb"
options), and the second, $i, is the file pointer, i keep track of it
exactly, since its a very exact requirement to parse these files.
the problem i got is this, gtnxt() is returning the correct byte value of
the byte @ $i, however, gt_8()is not, it is returning 00 (in every case of
it I could see).
I added debug lines into the code so that each time gtnxt() was called
followed by a gt_8() the file pointer and the value were commented into
the resultant html, so i could see why things were not going correctly.
Once I saw the issue was that the first read of the byte was correct but
the second read was incorrect, I suspected the possibility of the fseek in
gtnxt() not working correctly, and added in 2 new fseek lines (commented
out in the above code) which actually worked slightly better, allowing the
script to parse quite readily, but still showing the same problem further
on in the script (about 1000 bytes onward).
I uploaded the script as was to the site server, and it ran fine (apache
on redhat 7.1 running PHP4.1.2) so i knew the script worked fine.
I upgraded to 4.3.1 just in case (it had come out a day later) but I
expected no changes due to the explanantion of the 4.3.1 revision and was
correct, the same issue arose.
I downgraded PHP to 4.2.3 running ISAPI with the same results. I beleive
I was running ISAPI under 4.2.1 before the crash when i knew the script
worked ok.
Finally I decided to try running the CGI instead of ISAPI and all worked
fine. I upgraded back to 4.3.1 running CGI and everything worked fine
again.
The conclusion i came to is that ISAPI has a problem with either fseek()
or fread() but I cannot tell which.
One other change that I have not been able to test, is that the 'pickled'
file i am parsing has increased in size by 250% from 270k to about 680k
which may also be a factor.
--
Edit bug report at http://bugs.php.net/?id=22286&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22286&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22286&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22286&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22286&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22286&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=22286&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22286&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=22286&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=22286&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22286&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22286&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22286&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22286&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=22286&r=gnused
