#44859 [NEW]: is_readable() returns incorrect result
From: phpbugs at steve dot ipapp dot com
Operating system: Win 2000 SP4
PHP version: 5.2.5
PHP Bug Type: Filesystem function related
Bug description: is_readable() returns incorrect result
Description:
NT ACL Permissions can be modified in Windows by right clicking on the
file, going to properties, and security. Clicking the Everyone user and
hitting Deny Read, will prevent ANYTHING from reading, even if they have
READ permissions granted elsewhere.
is_readable() doesn't seem to care and thinks that all these files are
readable, when in fact they aren't. is_writeable() probably has the same
problem. Previous Bugs Identified with this have been closed: 41519.
Reproduce code:
---
$some_file = 'C:\\path\to\file.txt';
if(is_readable($some_file))
{
echo file_get_contents($some_file);
} else
{
echo This file isn't readable;
}
Expected result:
With NTFS ACL Permissions set to allow reading:
*Contents of File*
With NTFS ACL Permissions set to disallow reading:
This file isn't readable;
Actual result:
--
With NTFS ACL Permissions set to allow reading:
*Contents of File*
With NTFS ACL Permissions set to disallow reading:
Warning: file_get_contents(C:\\path\to\file.txt)
[function.file-get-contents]: failed to open stream: Permission denied in
C:\\path\to\script.php on line 4
--
Edit bug report at http://bugs.php.net/?id=44859edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44859r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44859r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44859r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44859r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44859r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44859r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44859r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44859r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44859r=support
Expected behavior:http://bugs.php.net/fix.php?id=44859r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44859r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44859r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44859r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44859r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44859r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44859r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44859r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44859r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44859r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44859r=mysqlcfg
#44411 [Opn]: Broken Compatibility
ID: 44411
User updated by: phpbugs at steve dot ipapp dot com
Reported By: phpbugs at steve dot ipapp dot com
Status: Open
Bug Type: SimpleXML related
Operating System: ANY
PHP Version: 5.2.5
New Comment:
But then what is the difference between strict comparision and loose
comparison for SimpleXMLObjects?
I'm then also unclear as to what exactly == was doing prior to 5.2.0.
It seemed to convey the idea atleast to me and one other person that the
classical object equality of 'if all the members are equal' seemed to
work. Furthermore if this functionality was not buggy or superious would
there be some way to have another method, perhaps equals() that achieves
this?
Previous Comments:
[2008-03-12 04:41:51] hubert dot roksor at gmail dot com
As per the manual chapter you quoted, the comparison operator compares
_objects_, and that's the key word here. You expect two equal XML trees
to be represented by two equal objects, and even though this expectation
is understandable, it is simply not the case. Those objects are
different. In fact, even if $sax1-value is equal to $sax1-value and
they come from the same tree, they are not identical. ($sax1-value !==
$sax1-value)
The bottom line is the comparison operator compares objects. If you
need an operator that understands the underlying data you will have to
use another mean. The solution proposed in the other bug report (compare
them as XML strings) sounds reasonable.
It would be nice to mention this quirk in the manual though, perhaps as
a new example? Comparing Elements and Elements
[2008-03-12 01:35:37] phpbugs at steve dot ipapp dot com
Description:
In PHP 5.0.x and 5.1.x two SimpleXMLElement objects were considered
equal if they represented the same data.
In PHP 5.2.x this does not seem to be the case anymore. This was
previously listed as bug 39866 [http://bugs.php.net/bug.php?id=39866],
but for some reason this was listed as bogus. In that bug it was noted
that we should look at Example 5 at http://php.net/simplexml. I'm
assuming this is Example 6 now [Comparing Elements and Attributes with
Text] , but this is incorrect as comparision will implicity cast
it to string anyway.
According to
http://www.php.net/manual/en/language.oop5.object-comparison.php:
When using the comparison operator (==), object variables are compared
in a simple manner, namely: Two object instances are equal if they have
the same attributes and values, and are instances of the same class...
On the other hand, when using the identity operator (===), object
variables are identical if and only if they refer to the same instance
of the same class.
Furthermore this backwards incompatible change is not listed in :
http://us.php.net/manual/en/migration52.incompatible.php.
Currently there is no equals method that we can call to get the
previous functionality back, and at the present moment this makes == no
longer transitive as especially since this makes == no longer
transitive as 'doc' == x1, 'doc' == x2, but x1 != x2.
I do not understand why ==, nor do I see value in, doing a strict
comparison for SimpleXMLObjects as ==, when according to the PHP Object
Comparison manual this should be ===.
Therefore I believe this is a bug.
Reproduce code:
---
$xmldoc = xmlvaluefoo/value/xml;
$sax1 = new SimpleXMLElement($xmldoc);
$sax2 = new SimpleXMLElement($xmldoc);
if($sax1 == $sax2)
{
echo TRUE;
} else
{
echo FALSE;
}
echo \n\n\n;
Expected result:
TRUE
Actual result:
--
FALSE
--
Edit this bug report at http://bugs.php.net/?id=44411edit=1
#44411 [NEW]: Broken Compatibility
From: phpbugs at steve dot ipapp dot com
Operating system: ANY
PHP version: 5.2.5
PHP Bug Type: SimpleXML related
Bug description: Broken Compatibility
Description:
In PHP 5.0.x and 5.1.x two SimpleXMLElement objects were considered equal
if they represented the same data.
In PHP 5.2.x this does not seem to be the case anymore. This was
previously listed as bug 39866 [http://bugs.php.net/bug.php?id=39866], but
for some reason this was listed as bogus. In that bug it was noted that we
should look at Example 5 at http://php.net/simplexml. I'm assuming this is
Example 6 now [Comparing Elements and Attributes with Text] , but this is
incorrect as comparision will implicity cast
it to string anyway.
According to
http://www.php.net/manual/en/language.oop5.object-comparison.php:
When using the comparison operator (==), object variables are compared in
a simple manner, namely: Two object instances are equal if they have the
same attributes and values, and are instances of the same class... On the
other hand, when using the identity operator (===), object variables are
identical if and only if they refer to the same instance of the same
class.
Furthermore this backwards incompatible change is not listed in :
http://us.php.net/manual/en/migration52.incompatible.php.
Currently there is no equals method that we can call to get the previous
functionality back, and at the present moment this makes == no longer
transitive as especially since this makes == no longer transitive as 'doc'
== x1, 'doc' == x2, but x1 != x2.
I do not understand why ==, nor do I see value in, doing a strict
comparison for SimpleXMLObjects as ==, when according to the PHP Object
Comparison manual this should be ===.
Therefore I believe this is a bug.
Reproduce code:
---
$xmldoc = xmlvaluefoo/value/xml;
$sax1 = new SimpleXMLElement($xmldoc);
$sax2 = new SimpleXMLElement($xmldoc);
if($sax1 == $sax2)
{
echo TRUE;
} else
{
echo FALSE;
}
echo \n\n\n;
Expected result:
TRUE
Actual result:
--
FALSE
--
Edit bug report at http://bugs.php.net/?id=44411edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44411r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44411r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44411r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44411r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44411r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44411r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44411r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44411r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44411r=support
Expected behavior:http://bugs.php.net/fix.php?id=44411r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44411r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44411r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44411r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44411r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44411r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44411r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44411r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44411r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44411r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44411r=mysqlcfg
