See Also

User Contributed Notes 23 notes

Note that is_file() returns false if the parent directory doesn't have +x set for you; this make sense, but other functions such as readdir() don't seem to have this limitation. The end result is that you can loop through a directory's files but is_file() will always fail.

if you're running apache as a service on a win32 machine, an you try to determinate if a file on an other pc in your network exists - ex.: is_file('//servername/share/dir1/dir2/file.txt') - you may return false when you're running the service as LocalSystem. To avoid this, you have to start the Apache-Service as a 'registered' domain user.

I've seen many scripts that take it for granted that a path is a directory when it fails is_file($path). When trying to determine whether a path links to a file or a dir, you should always use is_dir after getting false from is_file($path). For cases like described above, both will fail.

Maybe this is a newbie mistake, but note that paths are relative to the filesystem and the location of the script. This means that MS IIS virtual directories are not available by relative path - use an absolute.This threw me because virtual directories ARE available for URLs, at least on IIS.

I tend to use alot of includes, and I found that the is_file is based on the script executed, not ran.if you request /foo.php and foo.php looks like this:<?phpinclude('foobar/bar.php');?>and bar.php looks like this:<?phpecho (is_file('foo/bar.txt'));?>

Then PHP (on win32, php 5.x) would look for /foo/bar.txt and not /foobar/foo/bar.txt.you would have to rewrite the is_file statement for that, or change working directory.Noting this since I sat with the problem for some time,

It took me a day or so to figure out that is_file() actually looks for a valid $ existing path/file in string form. It is not performing a pattern-like test on the parameter given. Its testing to see if the given parameter leads to a specific existing 'name.ext' or other (non-directory) file type object.

In 32 bit environments, these functions including is_file(), stat() filesize() will not work due to PHPs default integer being signed. So anything above ~2.1 billion bytes you actually get a negative value.

This is actually a bug but I dont think there is an easy workaround. Try to switch to 64 bit.

Today I got the in the comments already described behaviour that between directory and file can't be distinguished by is_file() or is_dir().A dirty and incomplete hack is below, incomplete because it never includes links and I never tested what happens when a directory is not allowed to be read.

this is a simple way to find specific files instead of using is_file().
this example is made for mac standards, but easily changed for pc.

<?php
function isfile($file){
return preg_match('/^[^.^:^?^\-][^:^?]*\.(?i)' . getexts() . '$/',$file);
//first character cannot be . : ? - subsequent characters can't be a : ?
//then a . character and must end with one of your extentions
//getexts() can be replaced with your extentions pattern
}

It gets around the fact that, when working on website pages, the html files are read as directories when downloaded. It also allows you to extend the usefulness of the above method by adding the ability to determine file types e.g.