Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55909 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31017 invoked from network); 23 Oct 2011 13:46:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Oct 2011 13:46:26 -0000 Authentication-Results: pb1.pair.com smtp.mail=tom@punkave.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tom@punkave.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.212.42 as permitted sender) X-PHP-List-Original-Sender: tom@punkave.com X-Host-Fingerprint: 209.85.212.42 mail-vw0-f42.google.com Received: from [209.85.212.42] ([209.85.212.42:37122] helo=mail-vw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 52/E0-22525-1BA14AE4 for ; Sun, 23 Oct 2011 09:46:25 -0400 Received: by vwl1 with SMTP id 1so4365672vwl.29 for ; Sun, 23 Oct 2011 06:46:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.9 with SMTP id z9mr19560887vde.59.1319377581100; Sun, 23 Oct 2011 06:46:21 -0700 (PDT) Received: by 10.220.192.9 with HTTP; Sun, 23 Oct 2011 06:46:21 -0700 (PDT) In-Reply-To: <20111023125914.YUUV20122.aamtaout01-winn.ispmail.ntl.com@p2> References: <20111023125914.YUUV20122.aamtaout01-winn.ispmail.ntl.com@p2> Date: Sun, 23 Oct 2011 09:46:21 -0400 Message-ID: To: Jared Williams Cc: PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] fclose(), file_put_contents(), copy() all fail to return false on error From: tom@punkave.com (Tom Boutell) 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 wrote: > > Raised this 5 years ago.. > > http://marc.info/?l=php-internals&m=113998880315574&w=2 > > Jared > >> -----Original Message----- >> From: Tom Boutell [mailto:tom@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