php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #78885 hash_file now shows a notice for directories and returns false
Submitted: 2019-11-29 10:57 UTC Modified: 2020-11-03 18:09 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: php-bugs at xpaw dot me Assigned:
Status: Open Package: Filesystem function related
PHP Version: 7.4.0 OS: Linux
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: php-bugs at xpaw dot me
New email:
PHP Version: OS:

 

 [2019-11-29 10:57 UTC] php-bugs at xpaw dot me
Description:
------------
See https://3v4l.org/58RgW

Until 7.4.0beta1, it returned string(32) "d41d8cd98f00b204e9800998ecf8427e" and since 7.4.0beta2 it displays a notice.

Notice: hash_file(): read of 8192 bytes failed with errno=21 Is a directory in /in/58RgW on line 3

On Windows there is no notice, and it only returns false. I'm only creating this issue as I don't see anything in upgrading notes, deprecated features or the changelog about it.



Test script:
---------------
<?php
var_dump( hash_file( 'md5', '/etc/' ) );


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-11-29 12:34 UTC] cmb@php.net
-Package: hash +Package: Filesystem function related
 [2019-11-29 12:34 UTC] cmb@php.net
This is not particularly related to hash_file(), but also affects
other filesystem functions, see <https://3v4l.org/5XQB3>.  IIRC,
that was a very deliberate change/fix.
 [2019-11-29 14:05 UTC] cmb@php.net
-Assigned To: +Assigned To: nikic
 [2019-11-29 14:05 UTC] cmb@php.net
Well, the behavioral change has been introduced with commit
1cbcf0f[1]; not sure whether this particular behavior has been
anticipated.  If so, PR #4474[2] appears to be superfluous now.

[1] <http://git.php.net/?p=php-src.git;a=commit;h=1cbcf0f4f1e9a14b3fc76f6d3e53b567a9464fd4>
[2] <https://github.com/php/php-src/pull/4474>
 [2019-12-04 09:57 UTC] nikic@php.net
This is intentional. PR #4474 is also still relevant, because it is a change specific to includes (not normal file reads).

UPGRADING currently only mentions this change for fread() and fwrite() in particular, but of course it also affects many, many other filesystem functions that read/write internally. I don't think we want to exhaustively list everything that might be affected.
 [2020-11-03 18:09 UTC] cmb@php.net
-Status: Assigned +Status: Open -Type: Bug +Type: Documentation Problem -Assigned To: nikic +Assigned To:
 [2020-11-03 18:09 UTC] cmb@php.net
Changing to doc problem for now (IIRC, there is at least one
duplicate of this ticket).
 [2023-01-28 09:25 UTC] alisawefguxbpn53 at gmail dot com
That was so amazing
 [2023-01-28 09:25 UTC] alisaurgbfnbxbpn53 at gmail dot com
That was so amazing. (https://www.mypennmedicine.ltd/)github.com
 [2023-06-02 06:44 UTC] mypennmedicine dot online at gmail dot com
Thank you. Your example didn't work for me but I managed to fix it, which was basically the same thing!

(https://www.mypennmedicine.online/)github.com
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 03:01:29 2024 UTC