Re: Silenced include(_once) calls

On 3/4/06, Philippe Jausions <Philippe.Jausions@11abacus.com> wrote: > Yes, it's true there is an uncertainty, but not more than with > include/require(_once). There is a possible race condition by using > fopen then include. Uncertainty in that you don't know which file exactly you opened/included, right? But this isn't an issue. We don't care which one was opened or inlcuded, only that is *was*. Disregarding any concurrent processes on the system, fopen and include/require should use the same file if the include_path parameter is used in fopen. Actually I can see one case where this may not be true. If a file exists in the current path but '.' isn't in the include_path (or not in the beginning), then fopen may open the file relative to the current one but include/require may not. This would have to do with the way that fopen works. I'm not 100% sure as I haven't looked in the code but the docs say "if you want to search for the file in the include_path, too" which I take to mean it tries the normal opening (relative) and then tries the include_path. And once more, there is, of course, a problem if some other process on the system removes/renders unreadable the file in question between the fopen and the include (I'm assuming that this is the race condition mentioned). This I don't see as very/at all troubling. > > The real solution to gracefully detect failing includes would be to > fopen('r'), use the returned resource, pass it to fstat() to get the > actual fullpath of file that was actually opened. However the *stat() > functions don't return that information. > This sounds like an ok solution, but it *might* cause a relative file to be included when '.' is not in the include_path (see above) and it also breaks the idea of includes in PEAR. All PEAR includes are supposed to use relative paths so that, if another script included a file, then this will not include it again and cause duplicate class issues. > > > Wez Furlong wrote: > > It's not a locking issue, but an uncertainty issue. There is no way to > > tell which file you really opened. (actually, in more recent PHP 5 > > versions there is). > > > > I think you're remembering a conversation we had about fopen($file, 'w', > > true), which is a really bad idea. Of course it is. You'd truncate the file if you have write permissions. And if you don't (but do have read permissions) this call will fail, causing a failure when there shouldn't be one. > > > > --Wez. > > > > Lukas Smith wrote: > > > >>Justin Patrin wrote: > >> > >> > >>>>>3) Use @fopen($file, 'r', true). This is faster than #2 and still > >>>>>checks the include_path. This also does a check for readability in one > >>>>>call. This does use @, but in this case it has no horrible > >>>>>side-effects, such as the script dying. There are a few side-effects > >>>>>in that a registered PHP error handler will catch errors from this, > >>>>>but that is not likely to hurt an application in any way. This > >>>>>solution also allows an application to gracefully return an error > >>>>>without PHP errors being displayed. > >>>> > >>>>fopen() is not a good idea. I talked to Wez about this several years > >>>>back. It creates locking issues or something like that. I do not > >>>>remember the details. > >>> > >>>Ok. I'd never heard of fopen's include_path parameter before a few > >>>days ago and I was very surprised to find that it had one. If it's not > >>>for this type of thing....that what the heck is it for?? Could you > >>>find your e-mails about the locking? The code I would propose in this > >>>case is basically: > >>>$fp = @fopen($file, 'r', true); > >>>if ($fp === false) { > >>> return PEAR::raiseError('Could not find file '.$file.' in > >>>include_path'); > >>>} > >>>fclose($fp); > >>>include_once($file); > >>>If that causes locking issues then I suspect a bug in PHP... I know > >>>that others are using this code in their own projects with no problems > >>>(such as Paul M Jones' Solar). > >> > >>Yeah .. ZendFramework seems to use it as well .. > >> > >>I think I discussed with Wez on IRC, so I do not have any records of > >>this anymore. I CC'ed him .. maybe he can shed some light on this if his > >>time permits. > >> > >>regards, > >>Lukas > >> > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Justin Patrin