The path resolution process will assume that these entries have
their conventional meanings, regardless of whether they are
-actually present in the physical file system.
+actually present in the physical filesystem.
One cannot walk down past the root: "/.." is the same as "/".
.SS Mount points
After a "mount dev path" command, the pathname "path" refers to
-the root of the file system hierarchy on the device "dev", and no
+the root of the filesystem hierarchy on the device "dev", and no
longer to whatever it referred to earlier.
-One can walk out of a mounted file system: "path/.." refers to
+One can walk out of a mounted filesystem: "path/.." refers to
the parent directory of "path",
-outside of the file system hierarchy on "dev".
+outside of the filesystem hierarchy on "dev".
.SS Trailing slashes
If a pathname ends in a \(aq/\(aq, that forces resolution of the preceding
component as in Step 2: it has to exist and resolve to a directory.
changed by the system call
.BR setfsuid (2).
-(Here "fsuid" stands for something like "file system user ID".
+(Here "fsuid" stands for something like "filesystem user ID".
The concept was required for the implementation of a user space
NFS server at a time when processes could send a signal to a process
with the same effective user ID.
Nobody should use
.BR setfsuid (2).)
-Similarly, Linux uses the fsgid ("file system group ID")
+Similarly, Linux uses the fsgid ("filesystem group ID")
instead of the effective group ID.
See
.BR setfsgid (2).
-.\" FIXME say something about file system mounted read-only ?
+.\" FIXME say something about filesystem mounted read-only ?
.SS Bypassing permission checks: superuser and capabilities
On a traditional UNIX system, the superuser
.RI ( root ,
OSDN Git Service
