Allow invoking fsync

[phi-gamma]

The rationale is that often it is desired that directory metadata
be sync'd so changes become visible in the filesystem, in
particular after creating or renaming a file [0]. This is
necessary for some filesystems like ext4. To avoid races, the
call to fsync(2) must be passed the same fd that was used as the
target directory in the original operation (e. g. renamat(),
openat()).

In order for fsync to be effective, the fd must be equipped with
a full set of file operations kernel-side. Opening the directory
with O_PATH prevents this and attempts to fsync will fail with
EBADF. Thus an open variant Dir::open_full() is added that
omits the flag.

[0] https://lwn.net/Articles/457667/ (section: When should you
fsync?)

Signed-off-by: Philipp Gesang [email protected]

[phi-gamma]

So this implements just the bare minimum that I need
for reliably persisting files in directories that I use openat::Dir
handles for. As stated in the commit message, the goal is to
be able to call fsync(2) on such directories.

The sync_all() method is analogous to std::fs::File.
open_full() is just a suggestion. It might be preferable
to have something like open_with_flags() instead for the
user to customize the call to open() further e. g. by passing
O_DIRECTORY. Ideally we could use
std::os::unix::fs::OpenOptionsExt instead of raw bit
flags but that type is opaque and would have to be
duplicated.

[tailhook]

One quick question: why the method is called sync_all?

open_full is good, but we should also consider #18: i.e. we need open_flags for fuchsia, so we might as well provide it now.

Also we need either sub_dir with flags or propagate the flags (or both) as discussed in #18.

[phi-gamma]

One quick question: why the method is called sync_all?

Because that’s what the equivalent is called on std::fs::File:
https://doc.rust-lang.org/std/fs/struct.File.html#method.sync_all
Since this method exists I think it’s best to stick with that
nomenclature.

Also we need either sub_dir with flags or propagate the flags (or both) as discussed in #18

That would be reasonable, true. I’ll give it some thought.