This is Info file libc.info, produced by Makeinfo version 1.68 from the
input file libc.texinfo.

INFO-DIR-SECTION GNU libraries
START-INFO-DIR-ENTRY
* Libc: (libc).                 C library.
END-INFO-DIR-ENTRY

   This file documents the GNU C library.

   This is Edition 0.08 DRAFT, last updated 11 Jan 1999, of `The GNU C
Library Reference Manual', for Version 2.1 Beta.

   Copyright (C) 1993, '94, '95, '96, '97, '98, '99 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 translation of the section
entitled "GNU Library General Public License" must be approved for
accuracy by the Foundation.


File: libc.info,  Node: Working on Directory Trees,  Next: Hard Links,  Prev: Accessing Directories,  Up: File System Interface

Working on Directory Trees
==========================

   The functions to handle files in directories described so far
allowed to retrieve all the information in small pieces or process all
files in a directory (see `scandir').  Sometimes it is useful to
process whole hierarchies of directories and the contained files.  The
X/Open specification define two functions to do this.  The simpler form
is derived from an early definition in System V systems and therefore
this function is available on SVID derived systems.  The prototypes and
required definitions can be found in the `ftw.h' header.

   Both functions of this `ftw' family take as one of the arguments a
reference to a callback function.  The functions must be of these types.

 - Data Type: __ftw_func_t
          int (*) (const char *, const struct stat *, int)

     Type for callback functions given to the `ftw' function.  The first
     parameter will contain a pointer to the filename, the second
     parameter will point to an object of type `struct stat' which will
     be filled for the file named by the first parameter.

     The last parameter is a flag given more information about the
     current file.  It can have the following values:

    `FTW_F'
          The current item is a normal file or files which do not fit
          into one of the following categories.  This means especially
          special files, sockets etc.

    `FTW_D'
          The current item is a directory.

    `FTW_NS'
          The `stat' call to fill the object pointed to by the second
          parameter failed and so the information is invalid.

    `FTW_DNR'
          The item is a directory which cannot be read.

    `FTW_SL'
          The item is a symbolic link.  Since symbolic links are
          normally followed seeing this value in a `ftw' callback
          function means the referenced file does not exist.  The
          situation for `nftw' is different.

          This value is only available if the program is compiled with
          `_BSD_SOURCE' or `_XOPEN_EXTENDED' defined before including
          the first header.  The original SVID systems do not have
          symbolic links.

     If the sources are compiled with `_FILE_OFFSET_BITS == 64' this
     type is in fact `__ftw64_func_t' since this mode also changes
     `struct stat' to be `struct stat64'.

   For the LFS interface and the use in the function `ftw64' the header
`ftw.h' defines another function type.

 - Data Type: __ftw64_func_t
          int (*) (const char *, const struct stat64 *, int)

     This type is used just like `__ftw_func_t' for the callback
     function, but this time called from `ftw64'.  The second parameter
     to the function is this time a pointer to a variable of type
     `struct stat64' which is able to represent the larger values.

 - Data Type: __nftw_func_t
          int (*) (const char *, const struct stat *, int, struct FTW *)

     The first three arguments have the same as for the `__ftw_func_t'
     type.  A difference is that for the third argument some additional
     values are defined to allow finer differentiation:
    `FTW_DP'
          The current item is a directory and all subdirectories have
          already been visited and reported.  This flag is returned
          instead of `FTW_D' if the `FTW_DEPTH' flag is given to `nftw'
          (see below).

    `FTW_SLN'
          The current item is a stale symbolic link.  The file it
          points to does not exist.

     The last parameter of the callback function is a pointer to a
     structure with some extra information as described below.

     If the sources are compiled with `_FILE_OFFSET_BITS == 64' this
     type is in fact `__nftw64_func_t' since this mode also changes
     `struct stat' to be `struct stat64'.

   For the LFS interface there is also a variant of this data type
available which has to be used with the `nftw64' function.

 - Data Type: __nftw64_func_t
          int (*) (const char *, const struct stat64 *, int, struct FTW *)

     This type is used just like `__nftw_func_t' for the callback
     function, but this time called from `nftw64'.  The second parameter
     to the function is this time a pointer to a variable of type
     `struct stat64' which is able to represent the larger values.

 - Data Type: struct FTW
     The contained information helps to interpret the name parameter and
     gives some information about current state of the traversal of the
     directory hierarchy.

    `int base'
          The value specifies which part of the filename argument given
          in the first parameter to the callback function is the name
          of the file.  The rest of the string is the path to locate
          the file.  This information is especially important if the
          `FTW_CHDIR' flag for `nftw' was set since then the current
          directory is the one the current item is found in.

    `int level'
          While processing the directory the functions tracks how many
          directories have been examine to find the current item.  This
          nesting level is 0 for the item given starting item (file or
          directory) and is incremented by one for each entered
          directory.

 - Function: int ftw (const char *FILENAME, __ftw_func_t FUNC, int
          DESCRIPTORS)
     The `ftw' function calls the callback function given in the
     parameter FUNC for every item which is found in the directory
     specified by FILENAME and all directories below.  The function
     follows symbolic links if necessary but does not process an item
     twice.  If FILENAME names no directory this item is the only object
     reported by calling the callback function.

     The filename given to the callback function is constructed by
     taking the FILENAME parameter and appending the names of all passed
     directories and then the local file name.  So the callback
     function can use this parameter to access the file.  Before the
     callback function is called `ftw' calls `stat' for this file and
     passes the information up to the callback function.  If this
     `stat' call was not successful the failure is indicated by setting
     the falg argument of the callback function to `FTW_NS'.  Otherwise
     the flag is set according to the description given in the
     description of `__ftw_func_t' above.

     The callback function is expected to return 0 to indicate that no
     error occurred and the processing should be continued.  If an error
     occurred in the callback function or the call to `ftw' shall return
     immediately the callback function can return a value other than 0.
     This is the only correct way to stop the function.  The program
     must not use `setjmp' or similar techniques to continue the
     program in another place.  This would leave the resources
     allocated in the `ftw' function allocated.

     The DESCRIPTORS parameter to the `ftw' function specifies how many
     file descriptors the `ftw' function is allowed to consume.  The
     more descriptors can be used the faster the function can run.  For
     each level of directories at most one descriptor is used so that
     for very deep directory hierarchies the limit on open file
     descriptors for the process or the system can be exceeded.  Beside
     this the limit on file descriptors is counted together for all
     threads in a multi-threaded program and therefore it is always
     good too limit the maximal number of open descriptors to a
     reasonable number.

     The return value of the `ftw' function is 0 if all callback
     function calls returned 0 and all actions performed by the `ftw'
     succeeded.  If some function call failed (other than calling
     `stat' on an item) the function return -1.  If a callback function
     returns a value other than 0 this value is returned as the return
     value of `ftw'.

     When the sources are compiled with `_FILE_OFFSET_BITS == 64' on a
     32 bits system this function is in fact `ftw64'.  I.e., the LFS
     interface transparently replaces the old interface.

 - Function: int ftw64 (const char *FILENAME, __ftw64_func_t FUNC, int
          DESCRIPTORS)
     This function is similar to `ftw' but it can work on filesystems
     with large files since the information about the files is reported
     using a variable of type `struct stat64' which is passed by
     reference to the callback function.

     When the sources are compiled with `_FILE_OFFSET_BITS == 64' on a
     32 bits system this function is available under the name `ftw' and
     transparently replaces the old implementation.

 - Function: int nftw (const char *FILENAME, __nftw_func_t FUNC, int
          DESCRIPTORS, int FLAG)
     The `nftw' functions works like the `ftw' functions.  It calls the
     callback function FUNC for all items it finds in the directory
     FILENAME and below.  At most DESCRIPTORS file descriptors are
     consumed during the `nftw' call.

     The differences are that for one the callback function is of a
     different type.  It is of type `struct FTW *' and provides the
     callback functions the information described above.

     The second difference is that `nftw' takes an additional fourth
     argument which is 0 or a combination of any of the following
     values, combined using bitwise OR.

    `FTW_PHYS'
          While traversing the directory symbolic links are not
          followed.  I.e., if this flag is given symbolic links are
          reported using the `FTW_SL' value for the type parameter to
          the callback function.  Please note that if this flag is used
          the appearance of `FTW_SL' in a callback function does not
          mean the referenced file does not exist.  To indicate this
          the extra value `FTW_SLN' exists.

    `FTW_MOUNT'
          The callback function is only called for items which are on
          the same mounted filesystem as the directory given as the
          FILENAME parameter to `nftw'.

    `FTW_CHDIR'
          If this flag is given the current working directory is
          changed to the directory containing the reported object
          before the callback function is called.

    `FTW_DEPTH'
          If this option is given the function visits first all files
          and subdirectories before the callback function is called for
          the directory itself (depth-first processing).  This also
          means the type flag given to the callback function is
          `FTW_DP' and not `FTW_D'.

     The return value is computed in the same way as for `ftw'.  `nftw'
     return 0 if no failure occurred in `nftw' and all callback
     function call return values are also 0.  For internal errors such
     as memory problems -1 is returned and ERRNO is set accordingly.
     If the return value of a callback invocation is nonzero this very
     same value is returned.

     When the sources are compiled with `_FILE_OFFSET_BITS == 64' on a
     32 bits system this function is in fact `nftw64'.  I.e., the LFS
     interface transparently replaces the old interface.

 - Function: int nftw64 (const char *FILENAME, __nftw64_func_t FUNC,
          int DESCRIPTORS, int FLAG)
     This function is similar to `nftw' but it can work on filesystems
     with large files since the information about the files is reported
     using a variable of type `struct stat64' which is passed by
     reference to the callback function.

     When the sources are compiled with `_FILE_OFFSET_BITS == 64' on a
     32 bits system this function is available under the name `nftw' and
     transparently replaces the old implementation.


File: libc.info,  Node: Hard Links,  Next: Symbolic Links,  Prev: Working on Directory Trees,  Up: File System Interface

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 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 errors (*note File
     Name Errors::.) for both OLDNAME and NEWNAME, the following
     `errno' error conditions are defined for this function:

    `EACCES'
          You are not allowed to write the directory in which the new
          link is to be written.

    `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
          *Note Limits for Files::.)

    `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.

    `EIO'
          A hardware error occurred while trying to read or write the
          to filesystem.


File: libc.info,  Node: Symbolic Links,  Next: Deleting Files,  Prev: Hard Links,  Up: File System Interface

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 (*note 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 errors (*note 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.


File: libc.info,  Node: Deleting Files,  Next: Renaming Files,  Prev: Symbolic Links,  Up: File System Interface

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 (*note 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 errors (*note 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, or the directory has the sticky bit
          set and you do not own the file.

    `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.  (In the GNU system `unlink' can never delete
          the name of a directory.)

    `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 ISO C function to remove a file.  It works like
     `unlink' for files and like `rmdir' for directories.  `remove' is
     declared in `stdio.h'.


File: libc.info,  Node: Renaming Files,  Next: Creating Directories,  Prev: Deleting Files,  Up: File System Interface

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 errors (*note 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.

    `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.


File: libc.info,  Node: Creating Directories,  Next: File Attributes,  Prev: Renaming Files,  Up: File System Interface

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.  *Note 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 (*note 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: libc.info,  Node: File Attributes,  Next: Making Special Files,  Prev: Creating Directories,  Up: File System Interface

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.

* Menu:

* Attribute Meanings::          The names of the file attributes,
                                 and what their values mean.
* Reading Attributes::          How to read the attributes of a file.
* Testing File Type::           Distinguishing ordinary files,
                                 directories, links...
* File Owner::                  How ownership for new files is determined,
			         and how to change it.
* Permission Bits::             How information about a file's access
                                 mode is stored.
* Access Permission::           How the system decides who can access a file.
* Setting Permissions::         How permissions for new files are assigned,
			         and how to change them.
* Testing File Access::         How to find out if your process can
                                 access a file.
* File Times::                  About the time attributes of a file.
* File Size::			Manually changing the size of a file.


File: libc.info,  Node: Attribute Meanings,  Next: Reading Attributes,  Up: File Attributes

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 *Note 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 (*note Testing File Type::.) and the file
          permission bits (*note 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 as soon as no process still holds it open.
          Symbolic links are not counted in the total.

    `uid_t st_uid'
          The user ID of the file's owner.  *Note File Owner::.

    `gid_t st_gid'
          The group ID of the file.  *Note 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.  For symbolic links, this specifies the
          length of the file name the link refers to.

    `time_t st_atime'
          This is the last access time for the file.  *Note File
          Times::.

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

    `time_t st_mtime'
          This is the time of the last modification to the contents of
          the file.  *Note 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.  *Note File Times::.

    `time_t st_ctime'
          This is the time of the last modification to the attributes
          of the file.  *Note 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.  *Note File Times::.

    `blkcnt_t st_blocks'
          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'.)

   The extensions for the Large File Support (LFS) require even on 32
bits machine types which can handle file sizes up to 2^63.  Therefore a
new definition of `struct stat' is necessary.

 - Data Type: struct stat64
     The members of this type are the same and have the same names as
     those in `struct stat'.  The only difference is that the members
     `st_ino', `st_size', and `st_blocks' have a different type to
     support larger values.

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

    `ino64_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 as soon as no process still holds it open.
          Symbolic links are not counted in the total.

    `uid_t st_uid'
          The user ID of the file's owner.  *Note File Owner::.

    `gid_t st_gid'
          The group ID of the file.  *Note File Owner::.

    `off64_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.  For symbolic links, this specifies the
          length of the file name the link refers to.

    `time_t st_atime'
          This is the last access time for the file.  *Note File
          Times::.

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

    `time_t st_mtime'
          This is the time of the last modification to the contents of
          the file.  *Note 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.  *Note File Times::.

    `time_t st_ctime'
          This is the time of the last modification to the attributes
          of the file.  *Note 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.  *Note File Times::.

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

    `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'.

     If the source is compiled with `_FILE_OFFSET_BITS == 64' this type
     is transparently replaced by `ino64_t'.

 - Data Type: ino64_t
     This is an arithmetic data type used to represent file serial
     numbers for the use in LFS.  In the GNU system, this type is
     equivalent to `unsigned long longint'.

     When compiling with `_FILE_OFFSET_BITS == 64' this type is
     available under the name `ino_t'.

 - 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'.

 - Data Type: blkcnt_t
     This is an arithmetic data type used to represent block counts.
     In the GNU system, this is equivalent to `unsigned long int'.

     If the source is compiled with `_FILE_OFFSET_BITS == 64' this type
     is transparently replaced by `blkcnt64_t'.

 - Data Type: blkcnt64_t
     This is an arithmetic data type used to represent block counts for
     the use in LFS.  In the GNU system, this is equivalent to `unsigned
     long long int'.

     When compiling with `_FILE_OFFSET_BITS == 64' this type is
     available under the name `blkcnt_t'.


File: libc.info,  Node: Reading Attributes,  Next: Testing File Type,  Prev: Attribute Meanings,  Up: File Attributes

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 errors (*note File
     Name Errors::., the following `errno' error conditions are defined
     for this function:

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

     When the sources are compiled with `_FILE_OFFSET_BITS == 64' this
     function is in fact `stat64' since the LFS interface transparently
     replaces the normal implementation.

 - Function: int stat64 (const char *FILENAME, struct stat64 *BUF)
     This function is similar to `stat' but it is also able to work on
     file larger then 2^31 bytes on 32 bits systems.  To be able to do
     this the result is stored in a variable of type `struct stat64' to
     which BUF must point.

     When the sources are compiled with `_FILE_OFFSET_BITS == 64' this
     function is available under the name `stat' and so transparently
     replaces the interface for small fiels on 32 bits machines.

 - 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.  *Note
     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.

     When the sources are compiled with `_FILE_OFFSET_BITS == 64' this
     function is in fact `fstat64' since the LFS interface transparently
     replaces the normal implementation.

 - Function: int fstat64 (int FILEDES, struct stat64 *BUF)
     This function is similar to `fstat' but it is prepared to work on
     large files on 32 bits platforms.  For large files the file
     descriptor FILEDES should be returned by `open64' or `creat64'.
     The BUF pointer points to a variable of type `struct stat64' which
     is able to represent the larger values.

     When the sources are compiled with `_FILE_OFFSET_BITS == 64' this
     function is available under the name `fstat' and so transparently
     replaces the interface for small fiels on 32 bits machines.

 - 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'.  *Note Symbolic Links::.

     When the sources are compiled with `_FILE_OFFSET_BITS == 64' this
     function is in fact `lstat64' since the LFS interface transparently
     replaces the normal implementation.

 - Function: int lstat64 (const char *FILENAME, struct stat64 *BUF)
     This function is similar to `lstat' but it is also able to work on
     file larger then 2^31 bytes on 32 bits systems.  To be able to do
     this the result is stored in a variable of type `struct stat64' to
     which BUF must point.

     When the sources are compiled with `_FILE_OFFSET_BITS == 64' this
     function is available under the name `lstat' and so transparently
     replaces the interface for small fiels on 32 bits machines.


File: libc.info,  Node: Testing File Type,  Next: File Owner,  Prev: Reading Attributes,  Up: File Attributes

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,
*Note 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.  *Note Pipes and FIFOs::.

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

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

   An alternate 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: libc.info,  Node: File Owner,  Next: Permission Bits,  Prev: Testing File Type,  Up: File Attributes

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.  *Note 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 (*note 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 errors (*note 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.

          *Note 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.

