Description

Parameters

filename

If filename is of the form "scheme://...", it
is assumed to be a URL and PHP will search for a protocol handler
(also known as a wrapper) for that scheme. If no wrappers for that
protocol are registered, PHP will emit a notice to help you track
potential problems in your script and then continue as though
filename specifies a regular file.

If PHP has decided that filename specifies
a local file, then it will try to open a stream on that file.
The file must be accessible to PHP, so you need to ensure that
the file access permissions allow this access.
If you have enabled safe mode
or open_basedir further
restrictions may apply.

If PHP has decided that filename specifies
a registered protocol, and that protocol is registered as a
network URL, PHP will check to make sure that
allow_url_fopen is
enabled. If it is switched off, PHP will emit a warning and
the fopen call will fail.

Note:

The list of supported protocols can be found in Supported Protocols and Wrappers. Some protocols (also referred to as
wrappers) support context
and/or php.ini options. Refer to the specific page for the
protocol in use for a list of options which can be set. (e.g.
php.ini value user_agent used by the
http wrapper).

On the Windows platform, be careful to escape any backslashes
used in the path to the file, or use forward slashes.

<?php$handle = fopen("c:\\folder\\resource.txt", "r");?>

mode

The mode parameter specifies the type of access
you require to the stream. It may be any of the following:

A list of possible modes for fopen()
using mode

mode

Description

'r'

Open for reading only; place the file pointer at the
beginning of the file.

'r+'

Open for reading and writing; place the file pointer at
the beginning of the file.

'w'

Open for writing only; place the file pointer at the
beginning of the file and truncate the file to zero length.
If the file does not exist, attempt to create it.

'w+'

Open for reading and writing; place the file pointer at
the beginning of the file and truncate the file to zero
length. If the file does not exist, attempt to create it.

'a'

Open for writing only; place the file pointer at the end of
the file. If the file does not exist, attempt to create it.
In this mode, fseek() has no effect, writes are always appended.

'a+'

Open for reading and writing; place the file pointer at
the end of the file. If the file does not exist, attempt to
create it. In this mode, fseek() only affects
the reading position, writes are always appended.

'x'

Create and open for writing only; place the file pointer at the
beginning of the file. If the file already exists, the
fopen() call will fail by returning FALSE and
generating an error of level E_WARNING. If
the file does not exist, attempt to create it. This is equivalent
to specifying O_EXCL|O_CREAT flags for the
underlying open(2) system call.

'x+'

Create and open for reading and writing; otherwise it has the
same behavior as 'x'.

'c'

Open the file for writing only. If the file does not exist, it is
created. If it exists, it is neither truncated (as opposed to
'w'), nor the call to this function fails (as is
the case with 'x'). The file pointer is
positioned on the beginning of the file. This may be useful if it's
desired to get an advisory lock (see flock())
before attempting to modify the file, as using
'w' could truncate the file before the lock
was obtained (if truncation is desired,
ftruncate() can be used after the lock is
requested).

'c+'

Open the file for reading and writing; otherwise it has the same
behavior as 'c'.

'e'

Set close-on-exec flag on the opened file descriptor. Only
available in PHP compiled on POSIX.1-2008 conform systems.

Note:

Different operating system families have different line-ending
conventions. When you write a text file and want to insert a line
break, you need to use the correct line-ending character(s) for your
operating system. Unix based systems use \n as the
line ending character, Windows based systems use \r\n
as the line ending characters and Macintosh based systems use
\r as the line ending character.

If you use the wrong line ending characters when writing your files, you
might find that other applications that open those files will "look
funny".

Windows offers a text-mode translation flag ('t')
which will transparently translate \n to
\r\n when working with the file. In contrast, you
can also use 'b' to force binary mode, which will not
translate your data. To use these flags, specify either
'b' or 't' as the last character
of the mode parameter.

The default translation mode depends on the SAPI and version of PHP that
you are using, so you are encouraged to always specify the appropriate
flag for portability reasons. You should use the 't'
mode if you are working with plain-text files and you use
\n to delimit your line endings in your script, but
expect your files to be readable with applications such as notepad. You
should use the 'b' in all other cases.

If you do not specify the 'b' flag when working with binary files, you
may experience strange problems with your data, including broken image
files and strange problems with \r\n characters.

Note:

For portability, it is strongly recommended that you always
use the 'b' flag when opening files with fopen().

Note:

Again, for portability, it is also strongly recommended that
you re-write code that uses or relies upon the 't'
mode so that it uses the correct line endings and
'b' mode instead.

use_include_path

The optional third use_include_path parameter
can be set to '1' or TRUE if you want to search for the file in the
include_path, too.

context

Note: Context support was added
with PHP 5.0.0. For a description of contexts, refer to
Streams.

Return Values

Returns a file pointer resource on success, or FALSE on error.

Errors/Exceptions

If the open fails, an error of level
E_WARNING is generated. You may use @ to suppress this
warning.

Changelog

Version

Description

7.0.16, 7.1.2

The 'e' option were added.

5.2.6

The 'c' and 'c+' options were
added

4.3.2

As of PHP 4.3.2, the default mode is set to binary for all platforms
that distinguish between binary and text mode. If you are having
problems with your scripts after upgrading, try using the
't' flag as a workaround until you have made your
script more portable as mentioned before

Notes

Warning

When using SSL, Microsoft IIS
will violate the protocol by closing the connection without sending a
close_notify indicator. PHP will report this as "SSL: Fatal
Protocol Error" when you reach the end of the data. To work around this, the
value of error_reporting should be
lowered to a level that does not include warnings.
PHP can detect buggy IIS server software when you open
the stream using the https:// wrapper and will suppress the
warning. When using fsockopen() to create an
ssl:// socket, the developer is responsible for detecting
and suppressing this warning.

Note: When safe mode is enabled, PHP checks whether
the directory in which the script is operating has the same UID (owner) as the
script that is being executed.

Note:

If you are experiencing problems with reading and writing to files and
you're using the server module version of PHP, remember to make sure that
the files and directories you're using are accessible to the server
process.

Note:

This function may also succeed when filename is a
directory. If you are unsure whether filename is a
file or a directory, you may need to use the is_dir()
function before calling fopen().

User Contributed Notes 45 notes

Note - using fopen in 'w' mode will NOT update the modification time (filemtime) of a file like you may expect. You may want to issue a touch() after writing and closing the file which update its modification time. This may become critical in a caching situation, if you intend to keep your hair.

While opening a file with multibyte data (Ex: données multi-octets), faced some issues with the encoding. Got to know that it uses windows-1250. Used iconv to convert it to UTF-8 and it resolved the issue.

function checks if file exist, if not it will be created, if we have permission, without generate a warning/** * Check if folder exist and writable. * If not exist try to create it one writable. * * @return bool * true folder has been created or exist and writable. * False folder not exist and cannot be created. */function createWritableFolder($folder){ if($folder != '.' && $folder != '/' ) { createWritableFolder(dirname($folder)); } if (file_exists($folder)) { return is_writable($folder); }

"Do not use the following reserved device names for the name of a file:CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended. For more information, see Namespaces"it is a windows limitation.see:http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

If there is a file that´s excessively being rewritten by many different users, you´ll note that two almost-simultaneously accesses on that file could interfere with each other. For example if there´s a chat history containing only the last 25 chat lines. Now adding a line also means deleting the very first one. So while that whole writing is happening, another user might also add a line, reading the file, which, at this point, is incomplete, because it´s just being rewritten. The second user would then rewrite an incomplete file and add its line to it, meaning: you just got yourself some data loss!

If flock() was working at all, that might be the key to not let those interferences happen - but flock() mostly won´t work as expected (at least that´s my experience on any linux webserver I´ve tried), and writing own file-locking-functions comes with a lot of possible issues that would finally result in corrupted files. Even though it´s very unlikely, it´s not impossible and has happened to me already.

So I came up with another solution for the file-interference-problem:

1. A file that´s to be accessed will first be copied to a temp-file directory and its last filemtime() is being stored in a PHP-variable. The temp-file gets a random filename, ensuring no other process is able to interfere with this particular temp-file.2. When the temp-file has been changed/rewritten/whatever, there´ll be a check whether the filemtime() of the original file has been changed since we copied it into our temp-directory.2.1. If filemtime() is still the same, the temp-file will just be renamed/moved to the original filename, ensuring the original file is never in a temporary state - only the complete previous state or the complete new state.2.2. But if filemtime() has been changed while our PHP-process wanted to change its file, the temp-file will just be deleted and our new PHP-fileclose-function will return a FALSE, enabling whatever called that function to do it again (ie. upto 5 times, until it returns TRUE).

$overwriteanyway, one of the parameters for cfopen(), means: If cfclose() is used and the original file has changed, this script won´t care and still overwrite the original file with the new temp file. Anyway there won´t be any writing-interference between two PHP processes, assuming there can be no absolute simultaneousness between two (or more) processes.

If you need fopen() on a URL to timeout, you can do like:<?php $timeout = 3;$old = ini_set('default_socket_timeout', $timeout);$file = fopen('http://example.com', 'r');ini_set('default_socket_timeout', $old);stream_set_timeout($file, $timeout);stream_set_blocking($file, 0);//the rest is standard?>

I couldn't for the life of me get a certain php script working when i moved my server to a new Fedora 4 installation. The problem was that fopen() was failing when trying to access a file as a URL through apache -- even though it worked fine when run from the shell and even though the file was readily readable from any browser. After trying to place blame on Apache, RedHat, and even my cat and dog, I finally ran across this bug report on Redhat's website:

If you're using fopen to open a URL that requires authorization, you might need to force a HTTP/1.0 request for it since fopen won't support HTTP/1.1 requests. You can do that by setting your user_agent to one that is known only to support HTTP/1.0 (most webservers will be configured to force HTTP/1.0 for some browsers). Here's what worked for me:

This is an addendum to ibetyouare at home dot com's note about Apache directory permissions. If you are on a shared host and cannot tweak Apache's permissions directives then you might try setting the same thing in a .htaccess file. Failing that, if you are having trouble just creating files then set the directory permissions to allow writing (for whatever directory the file is supposed to be in) and include the following before fopen():

`touch /path/to/myfile/myfile.txt`;

That will usually create a new empty file that you can write to even when fopen fails. - PHP 4.3.0

If you're running PHP as apache module, it will always write files as "nobody", "www", "httpd", (or whatever user your webserver runs as) unless you specify a different user/group in httpd.conf, or compile apache with suexec support.
However, if you run PHP as a CGI wrapper, you may setuid the PHP executable to whatever user you wish (*severe* security issues apply). If you really want to be able to su to other user, I recommend compiling with suexec support.
AFAIK, PHP can't NOT use SuEXEC if apache does. If PHP is configured as an apache module it will act as whatever user the apache is. If apache SuEXEC's to otheruser:othergroup (e.g. root:root), that's what PHP will write files as, because it acts as a part of apache code. I suggest you double-check your SuEXEC configuration and settings. Note: you can't su to another user within the PHP code -- it has to be an apache directive, either through <VirtualHost>, or through .htaccess. Also note: I'm not sure how it all works (if it works at all) on Win32 platforms.
Check www.apache.org to see how it's done.

On a Windows webserver, when using fopen with a file path stored in a variable, PHP will return an error if the variable isn't encoded in ASCII, which may be the case if the file file path is retrieved from a database.

Be aware that fopen($url) also respects HTTP status headers. If the URL responds with a 1xx, 4xx, or 5xx status code, you will get a "failed to open stream: HTTP request failed!", followed by the HTTP status response. Same goes for file_get_contents($url)...

fopen() will block if the file to be opened is a fifo. This is true whether it's opened in "r" or "w" mode. (See man 7 fifo: this is the correct, default behaviour; although Linux supports non-blocking fopen() of a fifo, PHP doesn't).The consequence of this is that you can't discover whether an initial fifo read/write would block because to do that you need stream_select(), which in turn requires that fopen() has happened!

TIP: If you are using fopen and fread to read HTTP or FTP or Remote Files, and experiencing some performance issues such as stalling, slowing down and otherwise, then it's time you learned a thing called cURL.

Performance Comparison:

10 per minute for fopen/fread for 100 HTTP files2000 per minute for cURL for 2000 HTTP files

cURL should be used for opening HTTP and FTP files, it is EXTREMELY reliable, even when it comes to performance.

I noticed when using too many scripts at the same time to download the data from the site I was harvesting from, fopen and fread would go into deadlock. When using cURL i can open 50 windows, running 10 URL's from each window, and getting the best performance possible.

The reason is that truncating a file at size 0 forces the OS to deallocate all storage clusters used by the file, before you write your content which will be reallocated on disk.

The second code simply overwrites the existing content where it is already located on disk, and truncates any remaining bytes that may exist (if the new content is shorter than the old content). The "r+b" mode allows access for both read and write: the file can be kept opened after reading it and before rewriting the modified content.

It's particularly useful for files that are accessed often or have a size larger than a few kilobytes, as it saves lots of system I/O, and also limits the filesystem fragmentation if the updated file is quite large.

And this method also works if the file is locked exclusively once opened (but I would rather recommend using another empty file for locking purpose, opened with "a+" access mode, in "/var/lock/yourapp/*" or other fast filesystems where filelocks are easily monitored and where the webserver running PHP is allowed to create and update lock files, and not forgetting to close the lock file after closing the content file).

It seems that fopen() errors when you attempt opening a url starting with HTTP:// as opposed to http:// - it is case sensitive. In 4.3.1 anyway..."HTTP://", by not matching "http://" will tell the wrapper to look locally. From the looks of the source, the same goes for HTTPS vs https, etc.

I was working on a consol script for win32 and noticed a few things about it. On win32 it appears that you can't re-open the input stream for reading, but rather you have to open it once, and read from there on. Also, i don't know if this is a bug or what but it appears that fgets() reads until the new line anyway. The number of characters returned is ok, but it will not halt reading and return to the script. I don't know of a work around for this right now, but i'll keep working on it.

Quick tip. If using fopen to make http requests that contain a querystring, it is advised that you urlencode() your values, else characters like @ can make fopen (or whatever wrapper it is using) throw an error.

If you want to open large files (more than 2GB) that's what I did and it works: you should recompile your php with the CFLAGS="-D_FILE_OFFSET_BITS=64" ./configure etc... This tells to your compiler (I tested only gcc on PHP-4.3.4 binary on Linux and Solaris) to make the PHP parser binary large file aware. This way fopen() will not give you the "Value too large for defined data type" error message.God bless PHPciaoSergio Paternoster

While adding CFLAGS="-D_FILE_OFFSET_BITS=64" immediately before calling "./configure" on the PHP source will enable support for using fopen() on large files (greater than 2 GB), note that -- if such an installation of PHP is used in conjunction with Apache HTTPD [2.x], Apache will become completely unresponsive even when not serving output from a PHP application.

In order to gain large file support for non-web applications while maintaining the operability of Apache, consider making two distinct PHP installations: one with the above CFLAGS specified during configuration (for non-web uses), and the other without this flag (for use with Apache).

The verbal descriptions take a while to read through to get a feel for the expected results for fopen modes. This csv table can help break it down for quicker understanding to find which mode you are looking for:

Mode,Creates,Reads,Writes,Pointer Starts,Truncates File,Notes,Purposer,,y,,beginning,,fails if file doesn't exist,basic read existing filer+,,y,y,beginning,,fails if file doesn't exist,basic r/w existing filew,y,,y,beginning+end,y,,"create, erase, write file"w+,y,y,y,beginning+end,y,,"create, erase, write file with read option"a,y,,y,end,,,"write from end of file, create if needed"a+,y,y,y,end,,,"write from end of file, create if needed, with read options"x,y,,y,beginning,,fails if file exists,"like w, but prevents over-writing an existing file"x+,y,y,y,beginning,,fails if file exists,"like w+, but prevents over writing an existing file"c,y,,y,beginning,,,open/create a file for writing without deleting current contentc+,y,y,y,beginning,,,"open/create a file that is read, and then written back down"