Once a file or directory is open, subsequent requests to perform operations on a file
or directory can fail. This is because attributes are checked at the server on each
request. When permissions on the object are more restrictive at the server, your
operations on an open file descriptor will fail when NFS receives updates. When the
server unlinks the object or makes it unavailable, then your operations on an open
file descriptor will fail when NFS receives updates. The local Network File System
also affects operations that retrieve file or directory attributes. Recent changes at
the server may not be available at your client yet, and the server may return old
values for your operations.
For more information on the usage notes for integrated file system APIs, see
System API Reference,
SC41-4801.
open(), create(), and mkdir() APIs
If you try to re-create a file or directory that was recently deleted, the request may
fail. This is because the local data that NFS stores still has a record of the
existence of the file or directory. File or directory creation will succeed once you
update the local data.
fcntl() API
Reading and writing to a file with the Network File System relies on byte-range
locking to guarantee data integrity.To prevent data inconsistency, use the fcntl() API
to get locks and release locks.
For more information about byte-range locking, see “Locks and Recovery” on
page 74. For more information on the fcntl()API, see
System API Reference,
SC41-4801.
Unchanged APIs
These APIs do not take a file descriptor,directory pointer, or path name, and are
not creation functions. Therefore, NFS does not return the EACCES and ESTALE
error numbers for the following APIs.All other APIs may receive the EACCESS and
ESTALE error numbers.
vgetegid()
vgeteuid()
vgetgid()
vgetgrgid()
vgetgrnam()
vgetgroups()
vgetpwnam()
vgetpwuid()
vgetuid()
vsysconf()
vumask()
Chapter8. Integrated File System APIs and the Network File System 79