See bug #53328. This is a good candidate for trunk, for stable versions I fear (perhaps unfoundedly) that, because the return value of php_stream_close/free is almost always ignored, some wrappers might have gotten away with incorrect return values on the close handler.

This can definitely happen with the regular stdio stuff. stdio employs buffering 
as a matter of course. It is a serious bug, not a change in behavior.

As for stream wrappers, the documentation specifies what stream_flush is 
supposed to return, and fflush() would already be failing for people with bad 
stream wrappers who did not heed that documentation.

stream_close is not supposed to return anything but is not affected by this bug 
because stream_flush has already been called (and cheerfully ignored) before 
stream_close is called (I checked). 

So there is no need to change the behavior of stream_close (which would be a bc 
break). We just need to pay attention to what stream_flush is already telling 
us.

How about a close_checks_flush php.ini flag which defaults to false in 5.3 and to 
true in 5.4?

It would be nice if the return value of php_stream_close() was checked, but note that fclose() does not call php_stream_close(), it calls zend_list_delete(), which can't return anything sensible because rsrc_dtor_func_t returns void.

It would be ugly and difficult to change rsrc_dtor_func_t at this stage, and in any case, during shutdown or zval destruction we don't really care about flush failures. I think the way to go would be to call php_stream_close() from fclose() before calling the resource destructor. There probably won't be any dangling pointers, it looks pretty well guarded already.

As for cataphract's concern: we could audit all the wrapper close functions, there's not that many of them is there?

fclose() calls php_stream_close since PHP 5.4, see http://svn.php.net/viewvc?view=revision&revision=309491

This looks like a bug, I think it'd be fine to have the fix in 5.4. Any pull reqs 
with fixes?

Still a bug
PHP 5.4.14 (cli) (built: May  5 2013 12:09:08)

I am using gluster to write to a file and then in the middle of the write I 
perform a unplug power shutoff. Gluster goes into lock mode which is good, what 
it is supposed to do. Although php doesn't seem to do the right thing, I did a 
strace of the fclose and you can clearly see a -1 is sent, but php is ignoring 
it.

//Gluster shut off and gluster mount log shows volume down

//fwrite here although can succeed since it buffers
write(3, "Some Text 2", 11)             = 11
write(1, "int(11)\n", 8int(11)
)                = 8

// Performed fflush(), not sure about this one
write(1, "bool(true)\n", 11bool(true)
)            = 11

// Performed fclose() here
close(3)                                = -1 ENOTCONN (Transport endpoint is not 
connected)
write(1, "bool(true)\n", 11bool(true)

Please make this higher priority.

Same issue here using file_put_contents:

82607 open("hello.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
82607 fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
82607 lseek(3, 0, SEEK_CUR)             = 0
82607 write(3, "Hello, world", 12)      = 12
82607 close(3)                          = -1 EDQUOT (Disk quota exceeded)

Write succeeds but the close fails. file_put_contents doesn't check the result of the close:

https://github.com/php/php-src/blob/master/ext/standard/file.c#L695

Looks unlikely anybody is going to fix this though, given the age of this bug :-(

I have been looking into this and implemented initial changes in the linked PR. It needs more checking as noted in the PR though.