Information Technology Reference
In-Depth Information
Open vs. creat vs. stat
By default, the UNIX
open
system call returns an error if the application tries to open
a file that does not exist; as an option (not shown above), a parameter can tell the
kernel to instead create the file if it does not exist. Since UNIX also has system calls
for creating a file (
creat
) and for testing whether a file exists (
stat
), it might seem like
open
could be simplified to always assume that the file already exists.
However, UNIX often runs in a multi-user, multi-application environment, and in that
setting the issue of system call design can become more subtle. Suppose instead of the
UNIX interface, we had completely separate functions for testing if a file exists, creating
a file, and opening the file. Assuming that the user has permission to test, open, or
create the file, does this code work?
if(!exists(file)){
//ifthefiledoesn'texist
create(file);
//createit;areweguaranteedthefiledoesn'texist?
}
open(file)
//openthefile;areweguaranteedthefiledoesexist?
The problem is that on a multi-user system, some other user might have created the
file in between the call to test for its existence, and the call to create the file. Thus, call
to create must also test the existence of the file. Likewise, some other user might have
deleted the file between the call to create and the call to open. So open also needs the
ability to test if the file is there, and if not to create the file (if that is the user's intent).
UNIX addresses this with an all-purpose, atomic
open
: test if the file exists, option-
ally create it if it doesn't, and then open it. Because system calls are implemented in
the kernel, the operating system can make
open
(and all other I/O systems calls) non-
interruptable with respect to other system calls. If another user tries to delete a file while
the kernel is executing an
open
system call on the same file, the delete will be delayed
until the open completes. The open will return a file descriptor that will continue to work
until the application closes the file. The delete will remove the file from the file sys-
tem, but the file system does not actually reclaim its disk blocks until the file is closed.
returns immediately. This decouples the application from the device, al-
lowing each to go at their own speed. If the application generates data
faster than the device can receive it (as is common when spooling data to
a printer), the
write
system call blocks in the kernel until there is enough
room to store the new data in the buffer.
Explicit close. When an application is done with the device or file, it
calls
close
. This signals to the operating system that it can decrement
the reference-count on the device, and garbage collect any unused kernel
data structures.
For interprocess communication, we need two more system calls:
Pipes. A UNIX pipe is a kernel buffer with two file descriptors, one for
writing (to put data into the pipe) and one for reading (to pull data out
