# problem with include_path and write-based file functions - Thread: https://externals.io/message/42207 - Original archive: https://news-web.php.net/php.internals/42207 - Started by Gregory Beaver on 2008-12-09T19:50:21+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #42207 — Gregory Beaver — 2008-12-09T19:50:21+00:00 URL: https://externals.io/message/42207#42207 Hi, This bug: http://bugs.php.net/bug.php?id=46680 uncovers 2 larger issues. 1) Where should a function like `file_put_contents()` create its file if it doesn't already exist and `FILE_USE_INCLUDE_PATH` is 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. 2) 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. 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 --- ## #42208 — Marcus Boerger — 2008-12-09T20:11:02+00:00 URL: https://externals.io/message/42207#42208 · In reply to: #42207 Hello Gregory, Tuesday, December 9, 2008, 8:50:21 PM, you wrote: > Hi, > This bug: > http://bugs.php.net/bug.php?id=46680 > uncovers 2 larger issues. > 1) Where should a function like `file_put_contents()` create its file if > it doesn't already exist and `FILE_USE_INCLUDE_PATH` is 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. > 2) 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. > 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 --- ## #42215 — Daniel Convissor — 2008-12-10T18:33:02+00:00 URL: https://externals.io/message/42207#42215 · In reply to: #42207 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 --- ## #42306 — Lukas Kahwe Smith — 2008-12-17T20:02:30+00:00 URL: https://externals.io/message/42207#42306 · In reply to: #42215 > Hi: > > > > […] > > 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. 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 --- ## #42308 — Hannes Magnusson — 2008-12-17T21:24:49+00:00 URL: https://externals.io/message/42207#42308 · In reply to: #42306 > > 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 --- ## #42309 — Lukas Kahwe Smith — 2008-12-17T21:30:14+00:00 URL: https://externals.io/message/42207#42309 · In reply to: #42308 > On Wed, Dec 17, 2008 at 21:02, Lukas Kahwe Smith > wrote: > > […] > > That 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 --- ## #42310 — Hannes Magnusson — 2008-12-17T21:37:59+00:00 URL: https://externals.io/message/42207#42310 · In reply to: #42309 > > > > > […] > > > 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" 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 --- ## #42311 — Lukas Kahwe Smith — 2008-12-17T21:44:11+00:00 URL: https://externals.io/message/42207#42311 · In reply to: #42207 > 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