ID: 46680
Updated by: z...@php.net
Reported By: a...@php.net
-Status: No Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5.3CVS-2008-11-26 (snap)
Assigned To: dmitry
Previous Comments:
------------------------------------------------------------------------
[2008-12-18 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
------------------------------------------------------------------------
[2008-12-10 12:19:53] dmi...@php.net
I suppose the behavior in 5.3 is proper and the tests are wrong.
In 5.3 Both fopen() and file_put_contents() first look for file in
include path and in case of failure create new file in current working
directory. May be it should be changed to create it in first element of
include_path, but what should php to do if such directory doesn't
exist... Creation file in "script" directory (as 5.2 does, and what
tests expect) makes no sense.
BTW I don't see a lot of sense in usage of include_path with "create"
functions at all.
------------------------------------------------------------------------
[2008-12-09 19:37:29] cel...@php.net
first of all, the change from PHP 5.2 is the addition of
php_resolve_path, which is Dmitry's work. Second of all, most of the
tests are checking for *broken* behavior which is fixed in PHP 5.3.
file_put_contents('blah', 'whatever', FILE_USE_INCLUDE_PATH);
should not arbitrarily create the "blah" file in the first element of
the include_path. file_get_contents('blah', true) does not work this
way, it scans include_path for the file, and if not found, it tries as a
fallback to search in the current directory, and only then does it fail.
This is correct behavior - the file should be created in the current
directory if it does not already exist in the include_path. The
addition of the fallback was added in PHP 5.3, it seems.
The fopen tests also assume that fopen() with include_path parameter
for read will not check the current directory.
So we have a larger dilemma - the default include_path has the current
directory as the first element, and thus the functions that use
include_path for writing were acting as if they were doing the right
thing, when in fact they were making an arbitrary assumption about where
to put things.
None of this behavior is documented, so it is questionable what is the
right way to do things.
In other words, Jani is wrong to imply that anything I did caused the
problem, and should probably apologize, but I won't hold my breath.
I'm assigning to Dmitry under the assumption he will want to do the
ultimate commit, but will raise this on internals@
------------------------------------------------------------------------
[2008-11-26 10:15:48] a...@php.net
Description:
------------
The following tests were ported from 5.2.X and do not work as
expected on 5.3. The tests all create a test file and expect it to be
created in an include directory. Instead it looks like the file is
being created elsewhere This particularly affects file_put_contents()
with the FILE_USE_INCLUDE_PATH flag set, and also fopen(...).
Reproduce code:
---------------
See the tests now checked into CVS:
ext/standard/tests/file/file_put_contents_variation4.phpt
ext/standard/tests/file/file_put_contents_variation5.phpt
ext/standard/tests/file/file_put_contents_variation6.phpt
ext/standard/tests/file/fopen_variation5.phpt
ext/standard/tests/file/fopen_variation7.phpt
ext/standard/tests/file/fopen_variation8.phpt
ext/standard/tests/file/fopen_variation9.phpt
ext/standard/tests/file/fopen_variation12.phpt
ext/standard/tests/file/fopen_variation16.phpt
ext/standard/tests/file/fopen_variation17.phpt
Expected result:
----------------
See expected output in the PHPTs.
Actual result:
--------------
See the test results from running the PHPTs.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=46680&edit=1
