Slightly different - I agree that it's possible stream_close might need to signal a problem, but note that it is not responsible for flushing the output (because stream_flush is automatically called before stream_close).
It would go a long, long, long way to at least respect the return value of stream_flush, especially since the bug in question can affect plain old files too, and code that doesn't return a proper value from stream_flush is already bombing for anyone who checks the result of calling fflush(). So all I'm asking is for fclose() and its friends (copy(), file_put_contents()...) to pay attention when flush fails. Those of us who are trying to write stable stream wrappers can then just keep in mind that stream_flush is where the action is. The lack of a return value from stream_close is annoying but not insurmountable. However if folks are really so worried that respecting the return values of the flush functions will break existing (bad) code, a php.ini option could be added: close_checks_flush And turned on by those of us who would really like to know if our files are really there (: On Sun, Oct 23, 2011 at 8:59 AM, Jared Williams <jared.willia...@ntlworld.com> wrote: > > Raised this 5 years ago.. > > http://marc.info/?l=php-internals&m=113998880315574&w=2 > > Jared > >> -----Original Message----- >> From: Tom Boutell [mailto:t...@punkave.com] >> Sent: 21 October 2011 20:40 >> To: PHP Internals >> Subject: [PHP-DEV] fclose(), file_put_contents(), copy() all >> fail to return false on error >> >> It appears that all three of these functions do not return >> false on error as they should if the stream is not flushed >> successfully. Yipes! >> >> https://bugs.php.net/bug.php?id=60110 >> >> Am I missing something here? >> >> It's especially bad with, say, an S3 stream wrapper that >> wants to write the whole thing as one HTTP request, but it >> could bite you with plain old files too. >> >> -- >> Tom Boutell >> P'unk Avenue >> 215 755 1330 >> punkave.com >> window.punkave.com >> >> -- >> PHP Internals - PHP Runtime Development Mailing List To >> unsubscribe, visit: http://www.php.net/unsub.php >> > > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
