php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #70819 bzopen/fopen is not rewinded when accessing a file for the second time
Submitted: 2015-10-30 06:20 UTC Modified: 2017-01-11 16:19 UTC
From: mail at jerrygrey dot me Assigned:
Status: Open Package: Streams related
PHP Version: Irrelevant OS: Irrelevant
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mail at jerrygrey dot me
New email:
PHP Version: OS:

 

 [2015-10-30 06:20 UTC] mail at jerrygrey dot me 
Description:
------------
This looks like an old bug (from 12 years ago) first appearing here: http://php.net/manual/en/function.fflush.php#28887 It has reappeared via https://github.com/php/php-src/pull/1553

The function bzopen should automatically rewind the file pointer as per fopen() documentation for "r" mode: "...place the file pointer at the beginning of the file", but it doesn't. If this is by design, it should be included in the documentation. Since fopen is the base for bzopen, it might have the same issue too.

Test script:
---------------
<?php
$file = __DIR__ . DIRECTORY_SEPARATOR . 'bzflush_test.txt.bz2';
$text = "This is a test string.";

$bz1 = bzopen($file, 'w');
bzwrite($bz1, $text);
var_dump(bzflush($bz1));

$bz2 = bzopen($file, 'r');
var_dump(bzread($bz2));
bzclose($bz2);

bzclose($bz1);
?>

Expected result:
----------------
bool(true)
string(22) "This is a test string."

Actual result:
--------------
bool(true)
string(0) ""

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-11-01 15:20 UTC] reeze@php.net
-Type: Bug +Type: Documentation Problem
 [2015-11-01 15:20 UTC] reeze@php.net 
This might be a document problem.  
`bzflush()` is a no-op function,  https://github.com/enthought/bzip2/blob/master/bzlib.c#L1505

You could close it before next reading.


<?php
$file = __DIR__ . DIRECTORY_SEPARATOR . 'bzflush_test.txt.bz2';
$text = "This is a test string.";

$bz1 = bzopen($file, 'w');
bzwrite($bz1, $text);
var_dump(bzflush($bz1));

var_dump(file_get_contents($file));

bzclose($bz1);
var_dump(file_get_contents($file));
 [2015-11-01 15:28 UTC] mail at jerrygrey dot me 
In that case, should this function exist at all? It is just causing confusion.
 [2015-11-01 16:01 UTC] reeze@php.net 
@jerry  PHP just passthrough to zip library. maybe someday it will be implemented. We could fix the document to reflect that this function actually doing nothing. (we can't remove it for BC)
 [2016-01-01 22:04 UTC] salsi at icosaedro dot it 
My thoughs:

- Looking at source code, bzflush() simply calls fflush(). But this does not means all the data sent to the file with bzwrite() have been really written to disk: some are still in memory, where BZIP2 is building the current block of compressed data; some others are in internal buffer of the kernel, waiting to either complete a whole disk block or a file close.

- The original poster encountered a problem because he missed to close the stream with bzclose() and it made instead a fflush(). Then, writing only few bytes of data, this means nothing had really written to disk, and the following read failed returning an empty string.

- If the original poster had checked with bzerrno() or bzstrerr() the actual success of the bzread() operation, the result would be an "UNEXPECTED_EOF", indicating that something went wrong. This to stress how important (an difficult) may be to check errors properly, and how important and urgent may be to switch to exceptions everywhere as soon as possible :-)

- Finally, there is no bug here, and in my opinion this report should be closed as "not a bug".
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved. 		Last updated: Wed Jul 24 03:01:26 2019 UTC