File Systems: Introduction and Overview - Operating Systems: Principles and Practice - page 342

Modern File Access APIs
The API shown in Figure 11.6 is similar to most widely-used file access APIs, but it
is somewhat simplified.
For example, each of the listed calls is similar to a call provided by the Posix interface,
but the API shown in Figure 11.6 omits some arguments and options found in Posix.
The Posix open() call, for example, includes two additional arguments one to specify
various flags such as whether the file should be opened in read-only or read-write mode
and the other to specify the access control permissions that should be used if the open()
call creates a new file.
In addition, real-world file access APIs are likely to have a number of additional calls.
For example, the Microsoft Windows file access API includes dozens of calls including
calls to lock and unlock a file, to encrypt and decrypt a file, or to find a file in a directory
whose name matches a specific pattern.
file system into memory. When an application is done with a file, it can call
munmap() to remove the mappings.
Finally, the fsync() call is important for reliability. When an application
updates a file via a write() or a memory store to a mapped file, the updates
are buffered in memory and written back to stable storage at some future time.
Fsync() ensures that all pending updates for a file are written to persistent
storage before the call returns. Applications use this function for two purposes.
First, calling fsync() ensures that updates are durable and will not be lost if
there is a crash or power failure. Second, calling fsync() between two updates
ensures that the first is written to persistent storage before the second. Note
that calling fsync() is not always necessary; the operating system ensures that
all updates are made durable by periodically flushing all dirty file blocks to
stable storage.
Exercises
1. Discussion Suppose a process successfully opens an existing file that has
a single hard link to it, but while the process is reading that file, another
process unlinks that file. What should happen to subsequent reads by the
first process? Should they succeed? Should they fail? Why?
2. In Linux, suppose a process successfully opens an existing file that has a
single hard link to it, but while the process is reading that file, another
process unlinks that file? What happens to subsequent reads by the first
process? Do they succeed? Do they fail? (Answer this problem by con-
sulting documentation or by writing a program to test the behavior of the
system in this case.)