Re: Silenced include(_once) calls

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. --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 >