oepn sync

http://blog.csdn.net/cywosp/article/details/8767327

SYNOPSIS
       #include <sys/types.h>
       #include <sys/stat.h>
       #include <fcntl.h>

       int open(const char *pathname, int flags);
       int open(const char *pathname, int flags, mode_t mode);

       int creat(const char *pathname, mode_t mode);

DESCRIPTION
       Given  a pathname for a file, open() returns a file descriptor, a small,
       non-negative integer  for  use  in  subsequent  system  calls  (read(),
       write(),  lseek(), fcntl(), etc.).  The file descriptor returned by a
       successful call will be the lowest-numbered  file  descriptor  not  cur-
       rently open for the process.

       By  default,  the  new  file  descriptor is set to remain open across an
       execve() (i.e.,  the  FD_CLOEXEC  file  descriptor  flag  described  in
       fcntl()  is  initially  disabled;  the  Linux-specific  O_CLOEXEC flag,
       described below, can be used to change this default).  The  file  offset
       is set to the beginning of the file (see lseek()).

       A  call  to  open() creates a new open file description, an entry in the
       system-wide table of open files.  This entry records the file offset and
       the  file  status flags (modifiable via the fcntl() F_SETFL operation).
       A file descriptor is a reference to one of these entries; this reference
       is  unaffected  if pathname is subsequently removed or modified to refer
       to a different file.  The new open file  description  is  initially  not
       shared with any other process, but sharing may arise via fork().

       The  argument  flags  must  include  one  of the following access modes:
       O_RDONLY, O_WRONLY, or O_RDWR.  These request  opening  the  file  read-
       only, write-only, or read/write, respectively.

       In  addition, zero or more file creation flags and file status flags can
       be bitwise-or’d in flags.  The file creation flags are O_CREAT,  O_EXCL,
       O_NOCTTY,  and  O_TRUNC.  The file status flags are all of the remaining
       flags listed below.  The distinction between these two groups  of  flags
       is that the file status flags can be retrieved and (in some cases) modi-
       fied using fcntl().  The full list of file creation flags and file sta-
       tus flags is as follows:

       O_APPEND
              The  file  is  opened  in append mode.  Before each write(), the
              file offset is positioned at the end of  the  file,  as  if  with
              lseek().   O_APPEND may lead to corrupted files on NFS file sys-
              tems if more than one process appends data to  a  file  at  once.
              This  is because NFS does not support appending to a file, so the
              client kernel has to simulate it, which can’t be done  without  a
              race condition.

       O_ASYNC
              Enable  signal-driven  I/O:  generate a signal (SIGIO by default,
              but this can be  changed  via  fcntl())  when  input  or  output
              becomes  possible  on this file descriptor.  This feature is only
              available for terminals, pseudo-terminals,  sockets,  and  (since
              Linux 2.6) pipes and FIFOs.  See fcntl() for further details.

       O_CLOEXEC (Since Linux 2.6.)
              Enable the close-on-exec flag for the new file descriptor.  Spec-
              ifying this flag permits a program to avoid  additional  fcntl()
              F_SETFD operations to set the FD_CLOEXEC flag.  Additionally, use
              of this flag is essential in some  multithreaded  programs  since
              using a separate fcntl() F_SETFD operation to set the FD_CLOEXEC
              flag does not suffice to avoid race conditions where  one  thread
              opens a file descriptor at the same time as another thread does a
              fork() plus execve().

       O_CREAT
              If the file does not exist it will be created.  The  owner  (user
              ID)  of  the file is set to the effective user ID of the process.
              The group ownership (group ID) is set  either  to  the  effective
              group  ID  of the process or to the group ID of the parent direc-
              tory (depending on file system type and mount  options,  and  the
              mode of the parent directory, see the mount options bsdgroups and
              sysvgroups described in mount()).

              mode specifies the permissions to use in case a new file is  cre-
              ated.   This  argument must be supplied when O_CREAT is specified
              in flags; if O_CREAT is not specified, then mode is ignored.  The
              effective  permissions are modified by the process’s umask in the
              usual  way:   The   permissions   of   the   created   file   are
              (mode & ~umask).   Note  that  this  mode  only applies to future
              accesses of the newly created file; the open() call that  creates
              a read-only file may well return a read/write file descriptor.

              The following symbolic constants are provided for mode:

              S_IRWXU   user (file owner) has read, write and execute per-
                       mission

              S_IRUSR   user has read permission

              S_IWUSR   user has write permission

              S_IXUSR   user has execute permission

              S_IRWXG   group has read, write and execute permission

              S_IRGRP   group has read permission

              S_IWGRP   group has write permission

              S_IXGRP   group has execute permission

              S_IRWXO   others have read, write and execute permission

              S_IROTH   others have read permission

              S_IWOTH   others have write permission

              S_IXOTH   others have execute permission

       O_DIRECT (Since Linux 2.4.)
              Try to minimize cache effects of the I/O to and from  this  file.
              In  general  this  will  degrade performance, but it is useful in
              special situations,  such  as  when  applications  do  their  own
              caching.   File  I/O is done directly to/from user space buffers.
              The I/O is synchronous, that is, at the completion of  a  read()
              or  write(),  data  is guaranteed to have been transferred.  See
              NOTES below for further discussion.

              A semantically  similar  (but  deprecated)  interface  for  block
              devices is described in raw().

       O_DIRECTORY
              If  pathname  is  not  a directory, cause the open to fail.  This
              flag is Linux-specific, and was added in kernel version  2.1.,
              to  avoid denial-of-service problems if opendir() is called on a
              FIFO or tape device, but should not be used outside of the imple-
              mentation of opendir().

       O_EXCL Ensure that this call creates the file: if this flag is specified
              in conjunction with O_CREAT, and pathname  already  exists,  then
              open() will fail.  The behavior of O_EXCL is undefined if O_CREAT
              is not specified.

              When these two flags are specified, symbolic links are  not  fol-
              lowed:  if pathname is a symbolic link, then open() fails regard-
              less of where the symbolic link points to.

              O_EXCL is only supported on NFS when using NFSv3 or later on ker-
              nel  2.6  or  later.  In environments where NFS O_EXCL support is
              not provided, programs that rely on  it  for  performing  locking
              tasks will contain a race condition.  Portable programs that want
              to perform atomic file locking using  a  lockfile,  and  need  to
              avoid  reliance  on  NFS  support for O_EXCL, can create a unique
              file on the same file system (e.g.,  incorporating  hostname  and
              PID), and use link() to make a link to the lockfile.  If link()
              returns , the lock is successful.  Otherwise, use stat() on the
              unique  file  to  check  if its link count has increased to , in
              which case the lock is also successful.

       O_LARGEFILE
              (LFS) Allow files whose sizes cannot be represented in  an  off_t
              (but can be represented in an off64_t) to be opened.  The _LARGE-
              FILE64_SOURCE macro must be defined in order to obtain this defi-
              nition.   Setting  the _FILE_OFFSET_BITS feature test macro to
              (rather than  using  O_LARGEFILE)  is  the  preferred  method  of
              obtaining  method of accessing large files on -bit systems (see
              feature_test_macros()).

       O_NOATIME (Since Linux 2.6.)
              Do not update the file last access time (st_atime in  the  inode)
              when  the  file  is  read().   This  flag is intended for use by
              indexing or backup programs,  where  its  use  can  significantly
              reduce  the amount of disk activity.  This flag may not be effec-
              tive on all file systems.  One example is NFS, where  the  server
              maintains the access time.

       O_NOCTTY
              If  pathname  refers  to a terminal device — see tty() — it will
              not become the process’s controlling terminal even if the process
              does not have one.

       O_NOFOLLOW
              If  pathname  is a symbolic link, then the open fails.  This is a
              FreeBSD extension, which was added to Linux in  version  2.1..
              Symbolic  links  in earlier components of the pathname will still
              be followed.

       O_NONBLOCK or O_NDELAY
              When possible, the file is opened in non-blocking mode.   Neither
              the  open()  nor any subsequent operations on the file descriptor
              which is returned will cause the calling process  to  wait.   For
              the  handling  of  FIFOs  (named pipes), see also fifo().  For a
              discussion of the effect of O_NONBLOCK in conjunction with manda-
              tory file locks and with file leases, see fcntl().

       O_SYNC The  file  is  opened  for synchronous I/O.  Any write()s on the
              resulting file descriptor will block the  calling  process  until
              the  data has been physically written to the underlying hardware.
              But see NOTES below.

       O_TRUNC
              If the file already exists and is a regular  file  and  the  open
              mode  allows  writing  (i.e.,  is  O_RDWR or O_WRONLY) it will be
              truncated to length .  If the file is a FIFO or terminal  device
              file,  the  O_TRUNC  flag  is  ignored.   Otherwise the effect of
              O_TRUNC is unspecified.

       Some of these optional flags can be altered  using  fcntl()  after  the
       file has been opened.

       creat()    is    equivalent    to    open()    with   flags   equal   to
       O_CREAT|O_WRONLY|O_TRUNC.

  #include <unistd.h>

       int fsync(int fd);

       int fdatasync(int fd);

   Feature Test Macro Requirements for glibc (see feature_test_macros()):

       fsync(): _BSD_SOURCE || _XOPEN_SOURCE
                || /* since glibc 2.8: */ _POSIX_C_SOURCE >= 200112L
       fdatasync(): _POSIX_C_SOURCE >= 199309L || _XOPEN_SOURCE >= 

DESCRIPTION
       fsync() transfers ("flushes") all modified in-core data of (i.e.,  modi-
       fied buffer cache pages for) the file referred to by the file descriptor
       fd to the disk device (or other permanent  storage  device)  where  that
       file  resides.  The call blocks until the device reports that the trans-
       fer has completed.  It also flushes metadata information associated with
       the file (see stat()).

       Calling fsync() does not necessarily ensure that the entry in the direc-
       tory containing the file has also reached disk.  For  that  an  explicit
       fsync() on a file descriptor for the directory is also needed.

       fdatasync()  is similar to fsync(), but does not flush modified metadata
       unless that metadata is needed in  order  to  allow  a  subsequent  data
       retrieval  to be correctly handled.  For example, changes to st_atime or
       st_mtime (respectively, time of last access and time of  last  modifica-
       tion;  see  stat()) do not require flushing because they are not neces-
       sary for a subsequent data read to be handled correctly.  On  the  other
       hand,  a change to the file size (st_size, as made by say ftruncate()),
       would require a metadata flush.

       The aim of fdatasync() is to reduce disk activity for applications  that
       do not require all metadata to be synchronized with the disk.