   This file documents the GNU C library.

   This is Edition 0.06 DRAFT, last updated 24 October 1994, of `The
GNU C Library Reference Manual', for Version 1.09 Beta.

   Copyright (C) 1993, 1994 Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the section entitled "GNU Library General Public License" is
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the text of the translations of the section
entitled "GNU Library General Public License" must be approved for
accuracy by the Foundation.

Format of a Directory Entry
---------------------------

   This section describes what you find in a single directory entry, as
you might obtain it from a directory stream.  All the symbols are
declared in the header file `dirent.h'.

 - Data Type: struct dirent
     This is a structure type used to return information about directory
     entries.  It contains the following fields:

    `char d_name[]'
          This is the null-terminated file name component.  This is the
          only field you can count on in all POSIX systems.

    `ino_t d_fileno'
          This is the file serial number.  For BSD compatibility, you
          can also refer to this member as `d_ino'.  In the GNU system
          and most POSIX systems, for most files this the same as the
          `st_ino' member that `stat' will return for the file.  See
          File Attributes.

    `unsigned char d_namlen'
          This is the length of the file name, not including the
          terminating null character.  Its type is `unsigned char'
          because that is the integer type of the appropriate size

    `unsigned char d_type'
          This is the type of the file, possibly unknown.  The
          following constants are defined for its value:

         `DT_UNKNOWN'
               The type is unknown.  On some systems this is the only
               value returned.

         `DT_REG'
               A regular file.

         `DT_DIR'
               A directory.

         `DT_FIFO'
               A named pipe, or FIFO.  See FIFO Special Files.

         `DT_SOCK'
               A local-domain socket.

         `DT_CHR'
               A character device.

         `DT_BLK'
               A block device.

          This member is a BSD extension.  Each value except DT_UNKNOWN
          corresponds to the file type bits in the `st_mode' member of
          `struct statbuf'.  These two macros convert between `d_type'
          values and `st_mode' values:

           - Function: int IFTODT (mode_t MODE)
               This returns the `d_type' value corresponding to MODE.

           - Function: mode_t DTTOIF (int DIRTYPE)
               This returns the `st_mode' value corresponding to
               DIRTYPE.

     This structure may contain additional members in the future.

     When a file has multiple names, each name has its own directory
     entry.  The only way you can tell that the directory entries
     belong to a single file is that they have the same value for the
     `d_fileno' field.

     File attributes such as size, modification times, and the like are
     part of the file itself, not any particular directory entry.
     See File Attributes.

Opening a Directory Stream
--------------------------

   This section describes how to open a directory stream.  All the
symbols are declared in the header file `dirent.h'.

 - Data Type: DIR
     The `DIR' data type represents a directory stream.

   You shouldn't ever allocate objects of the `struct dirent' or `DIR'
data types, since the directory access functions do that for you.
Instead, you refer to these objects using the pointers returned by the
following functions.

 - Function: DIR * opendir (const char *DIRNAME)
     The `opendir' function opens and returns a directory stream for
     reading the directory whose file name is DIRNAME.  The stream has
     type `DIR *'.

     If unsuccessful, `opendir' returns a null pointer.  In addition to
     the usual file name syntax errors (see File Name Errors.), the
     following `errno' error conditions are defined for this function:

    `EACCES'
          Read permission is denied for the directory named by
          `dirname'.

    `EMFILE'
          The process has too many files open.

    `ENFILE'
          The entire system, or perhaps the file system which contains
          the directory, cannot support any additional open files at
          the moment.  (This problem cannot happen on the GNU system.)

     The `DIR' type is typically implemented using a file descriptor,
     and the `opendir' function in terms of the `open' function.  See
     Low-Level I/O.  Directory streams and the underlying file
     descriptors are closed on `exec' (see Executing a File.).

Reading and Closing a Directory Stream
--------------------------------------

   This section describes how to read directory entries from a directory
stream, and how to close the stream when you are done with it.  All the
symbols are declared in the header file `dirent.h'.

 - Function: struct dirent * readdir (DIR *DIRSTREAM)
     This function reads the next entry from the directory.  It normally
     returns a pointer to a structure containing information about the
     file.  This structure is statically allocated and can be rewritten
     by a subsequent call.

     *Portability Note:* On some systems, `readdir' may not return
     entries for `.' and `..', even though these are always valid file
     names in any directory.  See File Name Resolution.

     If there are no more entries in the directory or an error is
     detected, `readdir' returns a null pointer.  The following `errno'
     error conditions are defined for this function:

    `EBADF'
          The DIRSTREAM argument is not valid.

 - Function: int closedir (DIR *DIRSTREAM)
     This function closes the directory stream DIRSTREAM.  It returns
     `0' on success and `-1' on failure.

     The following `errno' error conditions are defined for this
     function:

    `EBADF'
          The DIRSTREAM argument is not valid.

Simple Program to List a Directory
----------------------------------

   Here's a simple program that prints the names of the files in the
current working directory:

     #include <stddef.h>
     #include <stdio.h>
     #include <sys/types.h>
     #include <dirent.h>

     int
     main (void)
     {
       DIR *dp;
       struct dirent *ep;

       dp = opendir ("./");
       if (dp != NULL)
         {
           while (ep = readdir (dp))
             puts (ep->d_name);
           (void) closedir (dp);
         }
       else
         puts ("Couldn't open the directory.");

       return 0;
     }

   The order in which files appear in a directory tends to be fairly
random.  A more useful program would sort the entries (perhaps by
alphabetizing them) before printing them; see Array Sort Function.

Random Access in a Directory Stream
-----------------------------------

   This section describes how to reread parts of a directory that you
have already read from an open directory stream.  All the symbols are
declared in the header file `dirent.h'.

 - Function: void rewinddir (DIR *DIRSTREAM)
     The `rewinddir' function is used to reinitialize the directory
     stream DIRSTREAM, so that if you call `readdir' it returns
     information about the first entry in the directory again.  This
     function also notices if files have been added or removed to the
     directory since it was opened with `opendir'.  (Entries for these
     files might or might not be returned by `readdir' if they were
     added or removed since you last called `opendir' or `rewinddir'.)

 - Function: off_t telldir (DIR *DIRSTREAM)
     The `telldir' function returns the file position of the directory
     stream DIRSTREAM.  You can use this value with `seekdir' to
     restore the directory stream to that position.

 - Function: void seekdir (DIR *DIRSTREAM, off_t POS)
     The `seekdir' function sets the file position of the directory
     stream DIRSTREAM to POS.  The value POS must be the result of a
     previous call to `telldir' on this particular stream; closing and
     reopening the directory can invalidate values returned by
     `telldir'.

Hard Links
==========

   In POSIX systems, one file can have many names at the same time.
All of the names are equally real, and no one of them is preferred to
the others.

   To add a name to a file, use the `link' function.  (The new name is
also called a "hard link" to the file.)  Creating a new link to a file
does not copy the contents of the file; it simply makes a new name by
which the file can be known, in addition to the file's existing name or
names.

   One file can have names in several directories, so the the
organization of the file system is not a strict hierarchy or tree.

   In most implementations, it is not possible to have hard links to the
same file in multiple file systems.  `link' reports an error if you try
to make a hard link to the file from another file system when this
cannot be done.

   The prototype for the `link' function is declared in the header file
`unistd.h'.

 - Function: int link (const char *OLDNAME, const char *NEWNAME)
     The `link' function makes a new link to the existing file named by
     OLDNAME, under the new name NEWNAME.

     This function returns a value of `0' if it is successful and `-1'
     on failure.  In addition to the usual file name syntax errors
     (see File Name Errors.) for both OLDNAME and NEWNAME, the
     following `errno' error conditions are defined for this function:

    `EACCES'
          The directory in which the new link is to be written is not
          writable.

    `EEXIST'
          There is already a file named NEWNAME.  If you want to replace
          this link with a new link, you must remove the old link
          explicitly first.

    `EMLINK'
          There are already too many links to the file named by OLDNAME.
          (The maximum number of links to a file is `LINK_MAX'; see
          Limits for Files.)

          Well-designed file systems never report this error, because
          they permit more links than your disk could possibly hold.
          However, you must still take account of the possibility of
          this error, as it could result from network access to a file
          system on another machine.

    `ENOENT'
          The file named by OLDNAME doesn't exist.  You can't make a
          link to a file that doesn't exist.

    `ENOSPC'
          The directory or file system that would contain the new link
          is "full" and cannot be extended.

    `EPERM'
          In the GNU system and some others, you cannot make links to
          directories.  many systems allow only privileged users to do
          so.  This error is used to report the problem.

    `EROFS'
          The directory containing the new link can't be modified
          because it's on a read-only file system.

    `EXDEV'
          The directory specified in NEWNAME is on a different file
          system than the existing file.

Symbolic Links
==============

   The GNU system supports "soft links" or "symbolic links".  This is a
kind of "file" that is essentially a pointer to another file name.
Unlike hard links, symbolic links can be made to directories or across
file systems with no restrictions.  You can also make a symbolic link
to a name which is not the name of any file.  (Opening this link will
fail until a file by that name is created.)  Likewise, if the symbolic
link points to an existing file which is later deleted, the symbolic
link continues to point to the same file name even though the name no
longer names any file.

   The reason symbolic links work the way they do is that special things
happen when you try to open the link.  The `open' function realizes you
have specified the name of a link, reads the file name contained in the
link, and opens that file name instead.  The `stat' function likewise
operates on the file that the symbolic link points to, instead of on
the link itself.

   By contrast, other operations such as deleting or renaming the file
operate on the link itself.  The functions `readlink' and `lstat' also
refrain from following symbolic links, because their purpose is to
obtain information about the link.  So does `link', the function that
makes a hard link-it makes a hard link to the symbolic link, which one
rarely wants.

   Prototypes for the functions listed in this section are in
`unistd.h'.

 - Function: int symlink (const char *OLDNAME, const char *NEWNAME)
     The `symlink' function makes a symbolic link to OLDNAME named
     NEWNAME.

     The normal return value from `symlink' is `0'.  A return value of
     `-1' indicates an error.  In addition to the usual file name
     syntax errors (see File Name Errors.), the following `errno'
     error conditions are defined for this function:

    `EEXIST'
          There is already an existing file named NEWNAME.

    `EROFS'
          The file NEWNAME would exist on a read-only file system.

    `ENOSPC'
          The directory or file system cannot be extended to make the
          new link.

    `EIO'
          A hardware error occurred while reading or writing data on
          the disk.

 - Function: int readlink (const char *FILENAME, char *BUFFER, size_t
          SIZE)
     The `readlink' function gets the value of the symbolic link
     FILENAME.  The file name that the link points to is copied into
     BUFFER.  This file name string is *not* null-terminated;
     `readlink' normally returns the number of characters copied.  The
     SIZE argument specifies the maximum number of characters to copy,
     usually the allocation size of BUFFER.

     If the return value equals SIZE, you cannot tell whether or not
     there was room to return the entire name.  So make a bigger buffer
     and call `readlink' again.  Here is an example:

          char *
          readlink_malloc (char *filename)
          {
            int size = 100;

            while (1)
              {
                char *buffer = (char *) xmalloc (size);
                int nchars = readlink (filename, buffer, size);
                if (nchars < size)
                  return buffer;
                free (buffer);
                size *= 2;
              }
          }

     A value of `-1' is returned in case of error.  In addition to the
     usual file name syntax errors (see File Name Errors.), the
     following `errno' error conditions are defined for this function:

    `EINVAL'
          The named file is not a symbolic link.

    `EIO'
          A hardware error occurred while reading or writing data on
          the disk.

Deleting Files
==============

   You can delete a file with the functions `unlink' or `remove'.

   Deletion actually deletes a file name.  If this is the file's only
name, then the file is deleted as well.  If the file has other names as
well (see Hard Links.), it remains accessible under its other names.

 - Function: int unlink (const char *FILENAME)
     The `unlink' function deletes the file name FILENAME.  If this is
     a file's sole name, the file itself is also deleted.  (Actually,
     if any process has the file open when this happens, deletion is
     postponed until all processes have closed the file.)

     The function `unlink' is declared in the header file `unistd.h'.

     This function returns `0' on successful completion, and `-1' on
     error.  In addition to the usual file name syntax errors (see
     File Name Errors.), the following `errno' error conditions are
     defined for this function:

    `EACCES'
          Write permission is denied for the directory from which the
          file is to be removed.

    `EBUSY'
          This error indicates that the file is being used by the
          system in such a way that it can't be unlinked.  For example,
          you might see this error if the file name specifies the root
          directory or a mount point for a file system.

    `ENOENT'
          The file name to be deleted doesn't exist.

    `EPERM'
          On some systems, `unlink' cannot be used to delete the name
          of a directory, or can only be used this way by a privileged
          user.  To avoid such problems, use `rmdir' to delete
          directories.  The GNU system

    `EROFS'
          The directory in which the file name is to be deleted is on a
          read-only file system, and can't be modified.

 - Function: int rmdir (const char *FILENAME)
     The `rmdir' function deletes a directory.  The directory must be
     empty before it can be removed; in other words, it can only contain
     entries for `.' and `..'.

     In most other respects, `rmdir' behaves like `unlink'.  There are
     two additional `errno' error conditions defined for `rmdir':

    `ENOTEMPTY'
    `EEXIST'
          The directory to be deleted is not empty.

     These two error codes are synonymous; some systems use one, and
     some use the other.  The GNU system always uses `ENOTEMPTY'.

     The prototype for this function is declared in the header file
     `unistd.h'.

 - Function: int remove (const char *FILENAME)
     This is the ANSI C function to remove a file.  It works like
     `unlink' for files and like `rmdir' for directories.  `remove' is
     declared in `stdio.h'.

Renaming Files
==============

   The `rename' function is used to change a file's name.

 - Function: int rename (const char *OLDNAME, const char *NEWNAME)
     The `rename' function renames the file name OLDNAME with NEWNAME.
     The file formerly accessible under the name OLDNAME is afterward
     accessible as NEWNAME instead.  (If the file had any other names
     aside from OLDNAME, it continues to have those names.)

     The directory containing the name NEWNAME must be on the same file
     system as the file (as indicated by the name OLDNAME).

     One special case for `rename' is when OLDNAME and NEWNAME are two
     names for the same file.  The consistent way to handle this case
     is to delete OLDNAME.  However, POSIX requires that in this case
     `rename' do nothing and report success--which is inconsistent.  We
     don't know what your operating system will do.

     If the OLDNAME is not a directory, then any existing file named
     NEWNAME is removed during the renaming operation.  However, if
     NEWNAME is the name of a directory, `rename' fails in this case.

     If the OLDNAME is a directory, then either NEWNAME must not exist
     or it must name a directory that is empty.  In the latter case,
     the existing directory named NEWNAME is deleted first.  The name
     NEWNAME must not specify a subdirectory of the directory `oldname'
     which is being renamed.

     One useful feature of `rename' is that the meaning of the name
     NEWNAME changes "atomically" from any previously existing file by
     that name to its new meaning (the file that was called OLDNAME).
     There is no instant at which NEWNAME is nonexistent "in between"
     the old meaning and the new meaning.  If there is a system crash
     during the operation, it is possible for both names to still
     exist; but NEWNAME will always be intact if it exists at all.

     If `rename' fails, it returns `-1'.  In addition to the usual file
     name syntax errors (see File Name Errors.), the following
     `errno' error conditions are defined for this function:

    `EACCES'
          One of the directories containing NEWNAME or OLDNAME refuses
          write permission; or NEWNAME and OLDNAME are directories and
          write permission is refused for one of them.

    `EBUSY'
          A directory named by OLDNAME or NEWNAME is being used by the
          system in a way that prevents the renaming from working.
          This includes directories that are mount points for
          filesystems, and directories that are the current working
          directories of processes.

    `ENOTEMPTY'
    `EEXIST'
          The directory NEWNAME isn't empty.  The GNU system always
          returns `ENOTEMPTY' for this, but some other systems return
          `EEXIST'.

    `EINVAL'
          The OLDNAME is a directory that contains NEWNAME.

    `EISDIR'
          The NEWNAME names a directory, but the OLDNAME doesn't.

    `EMLINK'
          The parent directory of NEWNAME would have too many links.

          Well-designed file systems never report this error, because
          they permit more links than your disk could possibly hold.
          However, you must still take account of the possibility of
          this error, as it could result from network access to a file
          system on another machine.

    `ENOENT'
          The file named by OLDNAME doesn't exist.

    `ENOSPC'
          The directory that would contain NEWNAME has no room for
          another entry, and there is no space left in the file system
          to expand it.

    `EROFS'
          The operation would involve writing to a directory on a
          read-only file system.

    `EXDEV'
          The two file names NEWNAME and OLDNAMES are on different file
          systems.

Creating Directories
====================

   Directories are created with the `mkdir' function.  (There is also a
shell command `mkdir' which does the same thing.)

 - Function: int mkdir (const char *FILENAME, mode_t MODE)
     The `mkdir' function creates a new, empty directory whose name is
     FILENAME.

     The argument MODE specifies the file permissions for the new
     directory file.  See Permission Bits, for more information
     about this.

     A return value of `0' indicates successful completion, and `-1'
     indicates failure.  In addition to the usual file name syntax
     errors (see File Name Errors.), the following `errno' error
     conditions are defined for this function:

    `EACCES'
          Write permission is denied for the parent directory in which
          the new directory is to be added.

    `EEXIST'
          A file named FILENAME already exists.

    `EMLINK'
          The parent directory has too many links.

          Well-designed file systems never report this error, because
          they permit more links than your disk could possibly hold.
          However, you must still take account of the possibility of
          this error, as it could result from network access to a file
          system on another machine.

    `ENOSPC'
          The file system doesn't have enough room to create the new
          directory.

    `EROFS'
          The parent directory of the directory being created is on a
          read-only file system, and cannot be modified.

     To use this function, your program should include the header file
     `sys/stat.h'.

File Attributes
===============

   When you issue an `ls -l' shell command on a file, it gives you
information about the size of the file, who owns it, when it was last
modified, and the like.  This kind of information is called the "file
attributes"; it is associated with the file itself and not a particular
one of its names.

   This section contains information about how you can inquire about and
modify these attributes of files.

What the File Attribute Values Mean
-----------------------------------

   When you read the attributes of a file, they come back in a structure
called `struct stat'.  This section describes the names of the
attributes, their data types, and what they mean.  For the functions to
read the attributes of a file, see Reading Attributes.

   The header file `sys/stat.h' declares all the symbols defined in
this section.

 - Data Type: struct stat
     The `stat' structure type is used to return information about the
     attributes of a file.  It contains at least the following members:

    `mode_t st_mode'
          Specifies the mode of the file.  This includes file type
          information (see Testing File Type.) and the file
          permission bits (see Permission Bits.).

    `ino_t st_ino'
          The file serial number, which distinguishes this file from
          all other files on the same device.

    `dev_t st_dev'
          Identifies the device containing the file.  The `st_ino' and
          `st_dev', taken together, uniquely identify the file.  The
          `st_dev' value is not necessarily consistent across reboots or
          system crashes, however.

    `nlink_t st_nlink'
          The number of hard links to the file.  This count keeps track
          of how many directories have entries for this file.  If the
          count is ever decremented to zero, then the file itself is
          discarded.  Symbolic links are not counted in the total.

    `uid_t st_uid'
          The user ID of the file's owner.  See File Owner.

    `gid_t st_gid'
          The group ID of the file.  See File Owner.

    `off_t st_size'
          This specifies the size of a regular file in bytes.  For
          files that are really devices and the like, this field isn't
          usually meaningful.

    `time_t st_atime'
          This is the last access time for the file.  See File Times.

    `unsigned long int st_atime_usec'
          This is the fractional part of the last access time for the
          file.  See File Times.

    `time_t st_mtime'
          This is the time of the last modification to the contents of
          the file.  See File Times.

    `unsigned long int st_mtime_usec'
          This is the fractional part of the time of last modification
          to the contents of the file.  See File Times.

    `time_t st_ctime'
          This is the time of the last modification to the attributes
          of the file.  See File Times.

    `unsigned long int st_ctime_usec'
          This is the fractional part of the time of last modification
          to the attributes of the file.  See File Times.

    `unsigned int st_nblocks'
          This is the amount of disk space that the file occupies,
          measured in units of 512-byte blocks.

          The number of disk blocks is not strictly proportional to the
          size of the file, for two reasons: the file system may use
          some blocks for internal record keeping; and the file may be
          sparse--it may have "holes" which contain zeros but do not
          actually take up space on the disk.

          You can tell (approximately) whether a file is sparse by
          comparing this value with `st_size', like this:

               (st.st_blocks * 512 < st.st_size)

          This test is not perfect because a file that is just slightly
          sparse might not be detected as sparse at all.  For practical
          applications, this is not a problem.

    `unsigned int st_blksize'
          The optimal block size for reading of writing this file, in
          bytes.  You might use this size for allocating the buffer
          space for reading of writing the file.  (This is unrelated to
          `st_blocks'.)

   Some of the file attributes have special data type names which exist
specifically for those attributes.  (They are all aliases for well-known
integer types that you know and love.)  These typedef names are defined
in the header file `sys/types.h' as well as in `sys/stat.h'.  Here is a
list of them.

 - Data Type: mode_t
     This is an integer data type used to represent file modes.  In the
     GNU system, this is equivalent to `unsigned int'.

 - Data Type: ino_t
     This is an arithmetic data type used to represent file serial
     numbers.  (In Unix jargon, these are sometimes called "inode
     numbers".) In the GNU system, this type is equivalent to `unsigned
     long int'.

 - Data Type: dev_t
     This is an arithmetic data type used to represent file device
     numbers.  In the GNU system, this is equivalent to `int'.

 - Data Type: nlink_t
     This is an arithmetic data type used to represent file link counts.
     In the GNU system, this is equivalent to `unsigned short int'.

Reading the Attributes of a File
--------------------------------

   To examine the attributes of files, use the functions `stat',
`fstat' and `lstat'.  They return the attribute information in a
`struct stat' object.  All three functions are declared in the header
file `sys/stat.h'.

 - Function: int stat (const char *FILENAME, struct stat *BUF)
     The `stat' function returns information about the attributes of the
     file named by FILENAME in the structure pointed at by BUF.

     If FILENAME is the name of a symbolic link, the attributes you get
     describe the file that the link points to.  If the link points to a
     nonexistent file name, then `stat' fails, reporting a nonexistent
     file.

     The return value is `0' if the operation is successful, and `-1'
     on failure.  In addition to the usual file name syntax errors
     (see File Name Errors., the following `errno' error conditions
     are defined for this function:

    `ENOENT'
          The file named by FILENAME doesn't exist.

 - Function: int fstat (int FILEDES, struct stat *BUF)
     The `fstat' function is like `stat', except that it takes an open
     file descriptor as an argument instead of a file name.  See
     Low-Level I/O.

     Like `stat', `fstat' returns `0' on success and `-1' on failure.
     The following `errno' error conditions are defined for `fstat':

    `EBADF'
          The FILEDES argument is not a valid file descriptor.

 - Function: int lstat (const char *FILENAME, struct stat *BUF)
     The `lstat' function is like `stat', except that it does not
     follow symbolic links.  If FILENAME is the name of a symbolic
     link, `lstat' returns information about the link itself; otherwise,
     `lstat' works like `stat'.  See Symbolic Links.

Testing the Type of a File
--------------------------

   The "file mode", stored in the `st_mode' field of the file
attributes, contains two kinds of information: the file type code, and
the access permission bits.  This section discusses only the type code,
which you can use to tell whether the file is a directory, whether it is
a socket, and so on.  For information about the access permission,
see Permission Bits.

   There are two predefined ways you can access the file type portion of
the file mode.  First of all, for each type of file, there is a
"predicate macro" which examines a file mode value and returns true or
false--is the file of that type, or not.  Secondly, you can mask out
the rest of the file mode to get just a file type code.  You can
compare this against various constants for the supported file types.

   All of the symbols listed in this section are defined in the header
file `sys/stat.h'.

   The following predicate macros test the type of a file, given the
value M which is the `st_mode' field returned by `stat' on that file:

 - Macro: int S_ISDIR (mode_t M)
     This macro returns nonzero if the file is a directory.

 - Macro: int S_ISCHR (mode_t M)
     This macro returns nonzero if the file is a character special file
     (a device like a terminal).

 - Macro: int S_ISBLK (mode_t M)
     This macro returns nonzero if the file is a block special file (a
     device like a disk).

 - Macro: int S_ISREG (mode_t M)
     This macro returns nonzero if the file is a regular file.

 - Macro: int S_ISFIFO (mode_t M)
     This macro returns nonzero if the file is a FIFO special file, or a
     pipe.  See Pipes and FIFOs.

 - Macro: int S_ISLNK (mode_t M)
     This macro returns nonzero if the file is a symbolic link.  See
     Symbolic Links.

 - Macro: int S_ISSOCK (mode_t M)
     This macro returns nonzero if the file is a socket.  See
     Sockets.

   An alterate non-POSIX method of testing the file type is supported
for compatibility with BSD.  The mode can be bitwise ANDed with
`S_IFMT' to extract the file type code, and compared to the appropriate
type code constant.  For example,

     S_ISCHR (MODE)

is equivalent to:

     ((MODE & S_IFMT) == S_IFCHR)

 - Macro: int S_IFMT
     This is a bit mask used to extract the file type code portion of a
     mode value.

   These are the symbolic names for the different file type codes:

`S_IFDIR'
     This macro represents the value of the file type code for a
     directory file.

`S_IFCHR'
     This macro represents the value of the file type code for a
     character-oriented device file.

`S_IFBLK'
     This macro represents the value of the file type code for a
     block-oriented device file.

`S_IFREG'
     This macro represents the value of the file type code for a
     regular file.

`S_IFLNK'
     This macro represents the value of the file type code for a
     symbolic link.

`S_IFSOCK'
     This macro represents the value of the file type code for a socket.

`S_IFIFO'
     This macro represents the value of the file type code for a FIFO
     or pipe.

File Owner
----------

   Every file has an "owner" which is one of the registered user names
defined on the system.  Each file also has a "group", which is one of
the defined groups.  The file owner can often be useful for showing you
who edited the file (especially when you edit with GNU Emacs), but its
main purpose is for access control.

   The file owner and group play a role in determining access because
the file has one set of access permission bits for the user that is the
owner, another set that apply to users who belong to the file's group,
and a third set of bits that apply to everyone else.  See Access Permission,
for the details of how access is decided based on this
data.

   When a file is created, its owner is set from the effective user ID
of the process that creates it (see Process Persona.).  The file's
group ID may be set from either effective group ID of the process, or
the group ID of the directory that contains the file, depending on the
system where the file is stored.  When you access a remote file system,
it behaves according to its own rule, not according to the system your
program is running on.  Thus, your program must be prepared to encounter
either kind of behavior, no matter what kind of system you run it on.

   You can change the owner and/or group owner of an existing file using
the `chown' function.  This is the primitive for the `chown' and
`chgrp' shell commands.

   The prototype for this function is declared in `unistd.h'.

 - Function: int chown (const char *FILENAME, uid_t OWNER, gid_t GROUP)
     The `chown' function changes the owner of the file FILENAME to
     OWNER, and its group owner to GROUP.

     Changing the owner of the file on certain systems clears the
     set-user-ID and set-group-ID bits of the file's permissions.
     (This is because those bits may not be appropriate for the new
     owner.)  The other file permission bits are not changed.

     The return value is `0' on success and `-1' on failure.  In
     addition to the usual file name syntax errors (see File Name Errors.),
     the following `errno' error conditions are defined for
     this function:

    `EPERM'
          This process lacks permission to make the requested change.

          Only privileged users or the file's owner can change the
          file's group.  On most file systems, only privileged users
          can change the file owner; some file systems allow you to
          change the owner if you are currently the owner.  When you
          access a remote file system, the behavior you encounter is
          determined by the system that actually holds the file, not by
          the system your program is running on.

          See Options for Files, for information about the
          `_POSIX_CHOWN_RESTRICTED' macro.

    `EROFS'
          The file is on a read-only file system.

 - Function: int fchown (int FILEDES, int OWNER, int GROUP)
     This is like `chown', except that it changes the owner of the file
     with open file descriptor FILEDES.

     The return value from `fchown' is `0' on success and `-1' on
     failure.  The following `errno' error codes are defined for this
     function:

    `EBADF'
          The FILEDES argument is not a valid file descriptor.

    `EINVAL'
          The FILEDES argument corresponds to a pipe or socket, not an
          ordinary file.

    `EPERM'
          This process lacks permission to make the requested change.
          For details, see `chmod', above.

    `EROFS'
          The file resides on a read-only file system.

The Mode Bits for Access Permission
-----------------------------------

   The "file mode", stored in the `st_mode' field of the file
attributes, contains two kinds of information: the file type code, and
the access permission bits.  This section discusses only the access
permission bits, which control who can read or write the file.  See
Testing File Type, for information about the file type code.

   All of the symbols listed in this section are defined in the header
file `sys/stat.h'.

   These symbolic constants are defined for the file mode bits that
control access permission for the file:

`S_IRUSR'
`S_IREAD'
     Read permission bit for the owner of the file.  On many systems,
     this bit is 0400.  `S_IREAD' is an obsolete synonym provided for
     BSD compatibility.

`S_IWUSR'
`S_IWRITE'
     Write permission bit for the owner of the file.  Usually 0200.
     `S_IWRITE' is an obsolete synonym provided for BSD compatibility.

`S_IXUSR'
`S_IEXEC'
     Execute (for ordinary files) or search (for directories)
     permission bit for the owner of the file.  Usually 0100.
     `S_IEXEC' is an obsolete synonym provided for BSD compatibility.

`S_IRWXU'
     This is equivalent to `(S_IRUSR | S_IWUSR | S_IXUSR)'.

`S_IRGRP'
     Read permission bit for the group owner of the file.  Usually 040.

`S_IWGRP'
     Write permission bit for the group owner of the file.  Usually 020.

`S_IXGRP'
     Execute or search permission bit for the group owner of the file.
     Usually 010.

`S_IRWXG'
     This is equivalent to `(S_IRGRP | S_IWGRP | S_IXGRP)'.

`S_IROTH'
     Read permission bit for other users.  Usually 04.

`S_IWOTH'
     Write permission bit for other users.  Usually 02.

`S_IXOTH'
     Execute or search permission bit for other users.  Usually 01.

`S_IRWXO'
     This is equivalent to `(S_IROTH | S_IWOTH | S_IXOTH)'.

`S_ISUID'
     This is the set-user-ID on execute bit, usually 04000.  See How Change Persona.

`S_ISGID'
     This is the set-group-ID on execute bit, usually 02000.  See How Change Persona.

`S_ISVTX'
     This is the "sticky" bit, usually 01000.

     On a directory, it gives permission to delete a file in the
     directory only if you own that file.  Ordinarily, a user either
     can delete all the files in the directory or cannot delete any of
     them (based on whether the user has write permission for the
     directory).  The same restriction applies--you must both have
     write permission for the directory and own the file you want to
     delete.  The one exception is that the owner of the directory can
     delete any file in the directory, no matter who owns it (provided
     the owner has given himself write permission for the directory).
     This is commonly used for the `/tmp' directory, where anyone may
     create files, but not delete files created by other users.

     Originally the sticky bit on an executable file modified the
     swapping policies of the system.  Normally, when a program
     terminated, its pages in core were immediately freed and reused.
     If the sticky bit was set on the executable file, the system kept
     the pages in core for a while as if the program were still
     running.  This was advantageous for a program likely to be run
     many times in succession.  This usage is obsolete in modern
     systems.  When a program terminates, its pages always remain in
     core as long as there is no shortage of memory in the system.
     When the program is next run, its pages will still be in core if
     no shortage arose since the last run.

     On some modern systems where the sticky bit has no useful meaning
     for an executable file, you cannot set the bit at all for a
     non-directory.  If you try, `chmod' fails with `EFTYPE'; see
     Setting Permissions..

     Some systems (particularly SunOS) have yet another use for the
     sticky bit.  If the sticky bit is set on a file that is *not*
     executable, it means the opposite: never cache the pages of this
     file at all.  The main use of this is for the files on an NFS
     server machine which are used as the swap area of diskless client
     machines.  The idea is that the pages of the file will be cached
     in the client's memory, so it is a waste of the server's memory to
     cache them a second time.  In this use the sticky bit also says
     that the filesystem may fail to record the file's modification
     time onto disk reliably (the idea being that noone cares for a
     swap file).

   The actual bit values of the symbols are listed in the table above
so you can decode file mode values when debugging your programs.  These
bit values are correct for most systems, but they are not guaranteed.

   *Warning:* Writing explicit numbers for file permissions is bad
practice.  It is not only nonportable, it also requires everyone who
reads your program to remember what the bits mean.  To make your
program clean, use the symbolic names.

How Your Access to a File is Decided
------------------------------------

   Recall that the operating system normally decides access permission
for a file based on the effective user and group IDs of the process,
and its supplementary group IDs, together with the file's owner, group
and permission bits.  These concepts are discussed in detail in
Process Persona.

   If the effective user ID of the process matches the owner user ID of
the file, then permissions for read, write, and execute/search are
controlled by the corresponding "user" (or "owner") bits.  Likewise, if
any of the effective group ID or supplementary group IDs of the process
matches the group owner ID of the file, then permissions are controlled
by the "group" bits.  Otherwise, permissions are controlled by the
"other" bits.

   Privileged users, like `root', can access any file, regardless of
its file permission bits.  As a special case, for a file to be
executable even for a privileged user, at least one of its execute bits
must be set.