[PHP-BUG] Bug #52587 [NEW]: Clearstatcache() has no effect

2010-08-11 Thread a-krcrai at microsoft dot com
From: 
Operating system: Windows
PHP version:  5.3.3
Package:  *Directory/Filesystem functions
Bug Type: Bug
Bug description:Clearstatcache() has no effect

Description:

The results of is_readable() and is_writable() are being cached from the
first result on a filesystem object regardless of whether or not
clearstatcache() is used or in what form (arguments supplied, etc).  This
has only been tested on the Windows build of PHP 5.3.3 via the CLI.  It's
possible that other functions are being improperly cached as well, but I
haven't had time to test for all of them as of yet.



This does *not*, however, occur in the corresponding Windows builds of PHP
5.3.2.  In that version, no caching took place on either of those functions
at all.



You can easily reproduce this issue if you're running Windows ACL-related
tests on the filesystem in PHP 5.3.3.  The sample script I put together
requires the use of SetACL (better cross-Windows version portability;
http://setacl.sourceforge.net) to alter the file permissions.  Relative to
the test script, create a directory named "testdir", then touch a file
within that directory and name it "testfile".  We will be using that file
for our test.





This bug occurs on the ZIP-build of PHP 5.3.3 (both nts and zts) run via
CLI without any extensions loaded.  It has been successfully reproduced in
Windows XP, Windows 2003, Windows 2003 R2, Windows Vista/7, Windows 2008,
and Windows 2008 R2.  Has not been tested on Linux.



Test script:
---
http://bugs.php.net/bug.php?id=52587&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52587&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52587&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=52587&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52587&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=52587&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52587&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=52587&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=52587&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=52587&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=52587&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=52587&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=52587&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=52587&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52587&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=52587&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52587&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=52587&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=52587&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=52587&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=52587&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=52587&r=mysqlcfg



Bug #52587 [Fbk->Opn]: Clearstatcache() has no effect

2010-08-11 Thread a-krcrai at microsoft dot com
Edit report at http://bugs.php.net/bug.php?id=52587&edit=1

 ID: 52587
 User updated by:    a-krcrai at microsoft dot com
 Reported by:    a-krcrai at microsoft dot com
 Summary:Clearstatcache() has no effect
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:*Directory/Filesystem functions
 Operating System:   Windows
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

If you're getting all true dumps, then that means that either you're
using 5.2.x (which I'm assuming you're not), or it means that the
directory/file exists but that the permissions aren't being successfully
applied (or some other weird ACL issue on your system).



This is because, even if you couldn't reproduce the bug, you should
still be getting false for the first two results, since full access is
being denied (meaning the file should be neither readable nor
writable).



Fortunately, debugging this is pretty simple.  I'd like you to do two
things for me, if you don't mind:



1. Pipe the exec calls to an array (see php.net/exec for details on how
to do this), then do a print_r() of said array and paste the output of
that here.  This will show us if SetACL is having trouble setting the
permissions on your system.



2. *Either*:



After the first pair of var_dumps, go ahead and temporarily toss in a
die() statement and re-run the script.  Then, from the command-line,
type "notepad testdir/testfile".  If the SetACL calls executed properly,
this should pop-up a Notepad window with an "Access Denied" popup
message.  If, on the other hand, Notepad loads your file just fine, then
that means the file is readable and thus the ACL permissions were never
applied.



*Or*:



If you have Powershell installed, open that and CD to whatever directory
your PHP script is in.  Then type "get-acl testdir/testfile |
format-list" and paste the output here.


Previous Comments:

[2010-08-12 04:42:25] ka...@php.net

Just did a test following the steps from your comment, my results are so
far:



php-trunk, VC9, x86, ZTS/NTS:

bool(true)

bool(true)

bool(true)

bool(true)



php-53, VC9, x86, ZTS/NTS:

bool(true)

bool(true)

bool(true)

bool(true)





I interpreted your steps as:

1) mkdir testdir

2) php -r "file_put_contents('./testdir/testfile', 'PHP on Windows');"

3) Make a php file with the above code inside

4) php bug52587.php



About ACL:

C:\php>setacl -help

SetACL by Helge Klein



Homepage:http://setacl.sourceforge.net

Version: 2.0.3.0

Copyright:   Helge Klein

License: GPL







Did you use VC6 or VC9 binaries for your testing?

------------
[2010-08-12 03:20:14] a-krcrai at microsoft dot com

Description:

The results of is_readable() and is_writable() are being cached from the
first result on a filesystem object regardless of whether or not
clearstatcache() is used or in what form (arguments supplied, etc). 
This has only been tested on the Windows build of PHP 5.3.3 via the CLI.
 It's possible that other functions are being improperly cached as well,
but I haven't had time to test for all of them as of yet.



This does *not*, however, occur in the corresponding Windows builds of
PHP 5.3.2.  In that version, no caching took place on either of those
functions at all.



You can easily reproduce this issue if you're running Windows
ACL-related tests on the filesystem in PHP 5.3.3.  The sample script I
put together requires the use of SetACL (better cross-Windows version
portability; http://setacl.sourceforge.net) to alter the file
permissions.  Relative to the test script, create a directory named
"testdir", then touch a file within that directory and name it
"testfile".  We will be using that file for our test.





This bug occurs on the ZIP-build of PHP 5.3.3 (both nts and zts) run via
CLI without any extensions loaded.  It has been successfully reproduced
in Windows XP, Windows 2003, Windows 2003 R2, Windows Vista/7, Windows
2008, and Windows 2008 R2.  Has not been tested on Linux.



Test script:
---
http://bugs.php.net/bug.php?id=52587&edit=1


Bug #52587 [Opn]: Clearstatcache() has no effect

2010-08-11 Thread a-krcrai at microsoft dot com
Edit report at http://bugs.php.net/bug.php?id=52587&edit=1

 ID: 52587
 User updated by:    a-krcrai at microsoft dot com
 Reported by:    a-krcrai at microsoft dot com
 Summary:Clearstatcache() has no effect
 Status: Open
 Type:   Bug
 Package:*Directory/Filesystem functions
 Operating System:   Windows
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

Oh, and this was reproduced on both VC6 and VC9 I'm pretty sure.


Previous Comments:

[2010-08-12 04:53:30] a-krcrai at microsoft dot com

If you're getting all true dumps, then that means that either you're
using 5.2.x (which I'm assuming you're not), or it means that the
directory/file exists but that the permissions aren't being successfully
applied (or some other weird ACL issue on your system).



This is because, even if you couldn't reproduce the bug, you should
still be getting false for the first two results, since full access is
being denied (meaning the file should be neither readable nor
writable).



Fortunately, debugging this is pretty simple.  I'd like you to do two
things for me, if you don't mind:



1. Pipe the exec calls to an array (see php.net/exec for details on how
to do this), then do a print_r() of said array and paste the output of
that here.  This will show us if SetACL is having trouble setting the
permissions on your system.



2. *Either*:



After the first pair of var_dumps, go ahead and temporarily toss in a
die() statement and re-run the script.  Then, from the command-line,
type "notepad testdir/testfile".  If the SetACL calls executed properly,
this should pop-up a Notepad window with an "Access Denied" popup
message.  If, on the other hand, Notepad loads your file just fine, then
that means the file is readable and thus the ACL permissions were never
applied.



*Or*:



If you have Powershell installed, open that and CD to whatever directory
your PHP script is in.  Then type "get-acl testdir/testfile |
format-list" and paste the output here.


[2010-08-12 04:42:25] ka...@php.net

Just did a test following the steps from your comment, my results are so
far:



php-trunk, VC9, x86, ZTS/NTS:

bool(true)

bool(true)

bool(true)

bool(true)



php-53, VC9, x86, ZTS/NTS:

bool(true)

bool(true)

bool(true)

bool(true)





I interpreted your steps as:

1) mkdir testdir

2) php -r "file_put_contents('./testdir/testfile', 'PHP on Windows');"

3) Make a php file with the above code inside

4) php bug52587.php



About ACL:

C:\php>setacl -help

SetACL by Helge Klein



Homepage:http://setacl.sourceforge.net

Version: 2.0.3.0

Copyright:   Helge Klein

License: GPL







Did you use VC6 or VC9 binaries for your testing?

--------
[2010-08-12 03:20:14] a-krcrai at microsoft dot com

Description:

The results of is_readable() and is_writable() are being cached from the
first result on a filesystem object regardless of whether or not
clearstatcache() is used or in what form (arguments supplied, etc). 
This has only been tested on the Windows build of PHP 5.3.3 via the CLI.
 It's possible that other functions are being improperly cached as well,
but I haven't had time to test for all of them as of yet.



This does *not*, however, occur in the corresponding Windows builds of
PHP 5.3.2.  In that version, no caching took place on either of those
functions at all.



You can easily reproduce this issue if you're running Windows
ACL-related tests on the filesystem in PHP 5.3.3.  The sample script I
put together requires the use of SetACL (better cross-Windows version
portability; http://setacl.sourceforge.net) to alter the file
permissions.  Relative to the test script, create a directory named
"testdir", then touch a file within that directory and name it
"testfile".  We will be using that file for our test.





This bug occurs on the ZIP-build of PHP 5.3.3 (both nts and zts) run via
CLI without any extensions loaded.  It has been successfully reproduced
in Windows XP, Windows 2003, Windows 2003 R2, Windows Vista/7, Windows
2008, and Windows 2008 R2.  Has not been tested on Linux.



Test script:
---
http://bugs.php.net/bug.php?id=52587&edit=1