Jump to content

Recommended Posts

I have encountered a strange problem that I hope someone might shed som light on for me...

 

After installing php 5 it seems that all filesystem functions fail, as if php can't see/read any files from within the website directory using filesystem functions, for instance file_exists() or file(). The strange part, however, is that including the same files using for instance include() or require() works just fine, as well as executing files that does not contain any file system functions.

 

Since this installation is on a customers system I do not have any further information than that it is a php 5.2.11 version installed on a Windows server (Windows Server 2003) and IIS 6.0 webservice. Server API ISAPI.

 

Does anyone have a clue what the problem might be?

Link to comment
https://forums.phpfreaks.com/topic/181213-problem-with-filesystem-functions/
Share on other sites

Ummm. What errors does php report as to why the function calls are failing when full php error_reporting/display_errors setting are turned on?

 

I'm going to guess you are using URL's in the function calls that are failing and you are using file paths in the function calls that work.

Ummm. What errors does php report as to why the function calls are failing when full php error_reporting/display_errors setting are turned on?

 

I'm going to guess you are using URL's in the function calls that are failing and you are using file paths in the function calls that work.

 

There are no errors logged (error_reporting set to E_ALL), and I cannot turn display_errors on since it is a production application.

 

Nope, no URL's, paths to files on the local server. 

You can disable specific functions using the disable_functions php.ini directive. The phpinfo() output will list if or which functions might have been disabled.

 

Oh, I didn't know that! However, the disable_functions directive is empty, so that's not the problem unfortunately.  :(

I cannot turn display_errors on since it is a production application.

 

Yes, you can. Even if just temporarily, long enough, to troubleshoot the problem, using an ini_set() statement, in your script.

 

Yes, but the same errors that would appear in the browser with display_errors turned on would as well be logged in the error log, right? And since I get nothing logged about this problem I won't be helped by turning display_errors on, or am I wrong?

 

If I do an extremely simple testfile executing only file_exists([path1]) or file([path1]) they return false, if I execute include([path1]) everything works as expected and the file is included. I can call the file from the browser directly and it will execute as well.

Without an actual example of what you are doing and the code doing it, best guess is that include/require works because the file can be found because it on the include_path statement. file_exists() returns false because the path being used is not correct for the current file where the code is being executed at and file() is not producing any php error either because it is either inside of a conditional statement so it is not actually being executed or your script is altering the error_reporting/display_errors/log_errors settings so that no error is reported.

What does a phpinfo() statement show for the actual error_reporting, log_errors, error_log, and display_errors settings?

 

Basically what you are saying (error_reporting/log_errors are set but the file() function is returning false and not reporting an error) is not possible unless the function has been disabled or the error related settings are not actually what you think they are.

What does a phpinfo() statement show for the actual error_reporting, log_errors, error_log, and display_errors settings?

 

Basically what you are saying (error_reporting/log_errors are set but the file() function is returning false and not reporting an error) is not possible unless the function has been disabled or the error related settings are not actually what you think they are.

 

Thanks for that information. I was pretty sure about that myself, but since the customer's host compay was very reluctant to show me the error log, and assured us that there were no such errors, I had nothing else to go on. But after adding some pressure about this they suddenly found the sought-after logged errors and sent them to me...  :facepalm:

 

I can reproduce the error by creating three simple files.

 

openme.txt containing

FooBar

 

testfile.php containing

<?php 
if (file("openme.txt")) echo "Happy happy joy joy!"; 
else echo "Nothing here, move on"; 
?>

 

testinclude.php containing

<?php
include("openme.txt");
?>

 

 

Result

When executing testinclude.php I get 'FooBar' as result.

When executing testfile.php I get 'Nothing here, move on'.

 

The error log says

PHP Warning: file(openme.txt) [<a
href='function.file'>function.file</a>]: failed to open stream: No such file or
directory in [fullpath]testfile.php on line 1

What does a phpinfo() statement show for the actual error_reporting, log_errors, error_log, and display_errors settings?

 

Oh, and the settings:

error_reporting

6143

6143

error_log

C:\PHP5\errorlog.txt

C:\PHP5\errorlog.txt

display_errors

Off

Off

log_errors

On

On

  • 2 weeks later...

Well. Since I couldn't find the problem, I installed the same php version on a win2003 server with IIS 6.0 here on a local virtual server. I chose fast cgi over isapi though. The web application worked just fine with the default settings from the installation. I recorded the whole installation process and the result with camtasia studio and sent the video (about 6 min) to the customer's hosting company to prove there's nothing wrong with the application. They made their php 5 install for this customer only, so they could probably reinstall it and fiddle with settings for it without any inconvenience for other customers.

 

I have not heard from either the customer nor the customer's hosting company in more than one week now, so I guess a reinstall with default settings solved the problem - whatever the problem was.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.