This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

aio_fsync() a directory ?

Hi folks!

As a followup to a discussion (<!topic/comp.unix.programmer/AM2V83RCOVE>) regarding synchronization of file operations (file creation, renaming, symlink, etc.), it seems that the only way to "commit" a filename change is to open() the containing directory in O_RDONLY, and fsync() the given file descriptor.

This behavior seems to work with fsync() [even if it is not really documented], and appears to have the expected side effects.

However, aio_fsync() [as tested in glibc 2.17) refuses to operate on a file descriptor not opened in write mode:

Extract from the glibc-2.17 sysdeps/pthread/aio_fsync.c:

aio_fsync (int op, struct aiocb *aiocbp)
  flags = fcntl (aiocbp->aio_fildes, F_GETFL);
  if (__builtin_expect (flags == -1, 0)
      || __builtin_expect ((flags & O_ACCMODE) == O_RDONLY, 0))
      __set_errno (EBADF);
      return -1;

This behavior is inconsistent with fsync() ; but OTOH it is consistent with the standard ; aio_fsync() "shall fail if the aio_fildes member of the aiocb structure referenced by the aiocbp argument is not a valid file descriptor open for writing"

Strangely, fsync() does not have this restriction (neither in the standard nor on the implementation) - was it on purpose ?

At last, is fsync'ing a directory the right way to commit operations on files entries ? If so, isn't it inconsistent not to accept this on the aio side ?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]