Hi,
This bug:
http://bugs.php.net/bug.php?id=46680
uncovers 2 larger issues.
- Where should a function like
file_put_contents()create its file if
it doesn't already exist andFILE_USE_INCLUDE_PATHis specified? The
test for this is ext/standard/file/file_put_contents_variation4.phpt and
a few others.
file_put_contents($filename, "File in include path", FILE_USE_INCLUDE_PATH);
arbitrarily creates $filename in the first portion of include_path on
PHP 5.2, and arbitrarily creates $filename in cwd in PHP 5.3. Of
course, if the file already exists in any of the include_path, both PHP
5.2 and 5.3 will overwrite it.
The same is true of fopen() in write mode.
- Should
file_get_contents()/fopen() in read mode fall back to current
directory if not found in include_path? The test for this is
ext/standard/file/fopen_variation5.phpt and others
In PHP 5.2, the functions simply fail if the file does not exist in
include_path. Thus if include_path does not contain ".", the file is
not found. In PHP 5.3, there is a fallback to check cwd for the file.
For #1 I think both PHP 5.2 and 5.3 are broken. If you specify that a
file should be written to inside include_path, it should fail if no file
is found - allowing arbitrary file creation is just plain stupid and
also dangerous - include_path has no business being used to create a
file, it should only be used to find existing files. In any case, I
think allowing include_path to be used at all for file modification is
horrendous, and think it should be deprecated and removed from PHP 6.
We should simply add file_resolve_path() function which can be used to
locate a file.
<?php
if ($path = file_resolve_path('somefile.txt')) {
file_put_contents($path, 'blah');
} else {
file_put_contents($someOtherPath, 'blah');
}
?>
For #2 I think PHP 5.3 is broken, and the fallback to cwd should be
removed from php_resolve_path.
Comments?
Greg
P.S. the tests themselves should not create directories outside of their
tests/ subdirectory, and should use things like PATH_SEPARATOR, but
that's a minor issue
Hello Gregory,
Tuesday, December 9, 2008, 8:50:21 PM, you wrote:
Hi,
This bug:
uncovers 2 larger issues.
- Where should a function like
file_put_contents()create its file if
it doesn't already exist andFILE_USE_INCLUDE_PATHis specified? The
test for this is ext/standard/file/file_put_contents_variation4.phpt and
a few others.
file_put_contents($filename, "File in include path", FILE_USE_INCLUDE_PATH);
arbitrarily creates $filename in the first portion of include_path on
PHP 5.2, and arbitrarily creates $filename in cwd in PHP 5.3. Of
course, if the file already exists in any of the include_path, both PHP
5.2 and 5.3 will overwrite it.
The same is true of
fopen()in write mode.
For existing files the include path makes very much sense to me. For non
existing files it does however not make much sense and we probably want
to issue an error in that case.
- Should
file_get_contents()/fopen() in read mode fall back to current
directory if not found in include_path? The test for this is
ext/standard/file/fopen_variation5.phpt and others
In PHP 5.2, the functions simply fail if the file does not exist in
include_path. Thus if include_path does not contain ".", the file is
not found. In PHP 5.3, there is a fallback to check cwd for the file.
For #1 I think both PHP 5.2 and 5.3 are broken. If you specify that a
file should be written to inside include_path, it should fail if no file
is found - allowing arbitrary file creation is just plain stupid and
also dangerous - include_path has no business being used to create a
file, it should only be used to find existing files. In any case, I
think allowing include_path to be used at all for file modification is
horrendous, and think it should be deprecated and removed from PHP 6.
We should simply add file_resolve_path() function which can be used to
locate a file.
<?php
if ($path = file_resolve_path('somefile.txt')) {
file_put_contents($path, 'blah');
} else {
file_put_contents($someOtherPath, 'blah');
}
?>>
For #2 I think PHP 5.3 is broken, and the fallback to cwd should be
removed from php_resolve_path.
Comments?
Agreed on #2
Greg
P.S. the tests themselves should not create directories outside of their
tests/ subdirectory, and should use things like PATH_SEPARATOR, but
that's a minor issue
Best regards,
Marcus
Hi:
I
think allowing include_path to be used at all for file modification is
horrendous, and think it should be deprecated and removed from PHP 6.
I agree.
To avoid compatibility issues between 5.2 and 5.3, it seems best that the
behavior not change in 5.3, though an E_DEPRECATED should be raised.
Then remove the functionality from 6.0.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Hi:
I
think allowing include_path to be used at all for file modification
is
horrendous, and think it should be deprecated and removed from PHP 6.I agree.
To avoid compatibility issues between 5.2 and 5.3, it seems best
that the
behavior not change in 5.3, though anE_DEPRECATEDshould be raised.
Then remove the functionality from 6.0.
which brings us back to the fact that we never added a proper way to
be able to determine if a file exists in the include path or not. this
is why a lot of people rely on fopen() for this. if we want to clean
this up, its high time we offer a proper solution for this. and i am
getting tired of the excuse, that file_exists() should not mess with
the include path. so lets add a new function or whatever. but this is
a common enough use case that we finally need to accept that we need
to provide a good solution.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
which brings us back to the fact that we never added a proper way to be able
to determine if a file exists in the include path or not. this is why a lot
That is simply not true. stream_resolve_include_path() is available in HEAD.
-Hannes
On Wed, Dec 17, 2008 at 21:02, Lukas Kahwe Smith
mls@pooteeweet.org wrote:which brings us back to the fact that we never added a proper way
to be able
to determine if a file exists in the include path or not. this is
why a lotThat is simply not true.
stream_resolve_include_path()is available
in HEAD.
cool. talk about a convoluted function name.
the documentation is probably not what we want though:
"stream_resolve_include_path — Determine what file will be opened by
calls to fopen() with a relative path"
it should rather talk about being able to determine what (if anything)
would be loaded on an include call.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
On Wed, Dec 17, 2008 at 21:02, Lukas Kahwe Smith mls@pooteeweet.org
wrote:which brings us back to the fact that we never added a proper way to be
able
to determine if a file exists in the include path or not. this is why a
lotThat is simply not true.
stream_resolve_include_path()is available in
HEAD.cool. talk about a convoluted function name.
the documentation is probably not what we want though:
"stream_resolve_include_path — Determine what file will be opened by calls
tofopen()with a relative path"
While the docs for 5.3 are extremely poor, documenting stuff in HEAD
is not a priority. But hey, concrete suggestions are always welcome :)
-Hannes
file, it should only be used to find existing files. In any case, I
think allowing include_path to be used at all for file modification is
horrendous, and think it should be deprecated and removed from PHP 6.
We should simply add file_resolve_path() function which can be used to
locate a file.
Since we have stream_resolve_include_path(), I guess we can make this
suggestion a reality.
Deprecate the ability to mess with the include path in fopen()/
file_get_contents() or any other method/function that can do write
operations. this btw imho also includes the cases when these functions
(for example fopen()) are using in read mode.
Speak now or forever hold your peace ..
regards,
Lukas Kahwe Smith
mls@pooteeweet.org