Edit report at https://bugs.php.net/bug.php?id=74411&edit=1
ID: 74411
Updated by: [email protected]
Reported by: miklcct at gmail dot com
Summary: SplFileInfo::getRealPath() returns false if
containing folder is unreadable
-Status: Open
+Status: Duplicate
Type: Documentation Problem
Package: Filesystem function related
Operating System: Windows 10
PHP Version: 7.1.3
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
> I'm using SplFileInfo, not bare functions. What the bare
> functions do is completely irrelevant to me.
Both use the same underlying implementation.
> Folder permission:
> All but list folder / read data
But these are required[1]. That might be something we want to
change in the future, but shouldn't in a a stable version.
So, basically, this is a duplicate of bug #43817.
[1] <https://bugs.php.net/bug.php?id=43817#1632409714>
Previous Comments:
------------------------------------------------------------------------
[2017-05-08 04:14:26] miklcct at gmail dot com
Folder permission:
All but list folder / read data
File permission:
Full control
------------------------------------------------------------------------
[2017-05-02 17:44:18] [email protected]
What are the exact ACLs on the folder and the file?
Thanks.
------------------------------------------------------------------------
[2017-04-11 14:02:11] miklcct at gmail dot com
I don't think it is a documentation issue, because
1. I'm using SplFileInfo, not bare functions. What the bare functions do is completely irrelevant to me.
2. Even it replicates the behaviour of that function, I have only denied the list content (read) permission but not traverse folder (execute) permission.
------------------------------------------------------------------------
[2017-04-11 13:51:47] [email protected]
It seems to me that is rather a documentation issue, as for
realpath() it is already noted[1] that:
| The running script must have executable permissions on all
| directories in the hierarchy, otherwise realpath() will return
| FALSE.
[1] <http://php.net/manual/en/function.realpath.php#refsect1-function.realpath-returnvalues>
------------------------------------------------------------------------
[2017-04-11 08:18:52] miklcct at gmail dot com
Description:
------------
On Windows, SplFileInfo::getRealPath() returns false if the containing folder is not readable even if the file itself is readable. This breaks in typical usage scenario where a SplFileInfo object is constructed using an uploaded file in temporary folder on Windows because the temporary folder in Windows is not readable by default, but creating files are allowed inside.
To reproduce, follow the below steps:
1. Make directory C:\dir
2. Make file C:\dir\file and put some text inside
3. Run the script, ensure that the second var_dump returns the path
4. Add an NTFS permission entry on C:\dir saying "deny everyone on this folder only advanced permission list folder / read data"
5. Run the script again
Test script:
---------------
<?php
$path = 'C:\dir\file';
$file = new SplFileInfo($path);
var_dump(file_get_contents($path));
var_dump($file);
var_dump($file->getRealPath());
Expected result:
----------------
Output similar to the below on both runs:
M:\splfileinfo_bug.php:4:
string(5) "test
"
M:\splfileinfo_bug.php:5:
class SplFileInfo#1 (2) {
private $pathName =>
string(11) "C:\dir\file"
private $fileName =>
string(4) "file"
}
M:\splfileinfo_bug.php:6:
string(11) "C:\dir\file"
Actual result:
--------------
After denying permission, the script outputs:
M:\splfileinfo_bug.php:4:
string(5) "test
"
M:\splfileinfo_bug.php:5:
class SplFileInfo#1 (2) {
private $pathName =>
string(11) "C:\dir\file"
private $fileName =>
string(4) "file"
}
M:\splfileinfo_bug.php:6:
bool(false)
Note that the file is readable but SplFileInfo::getRealPath() returns false.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=74411&edit=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.