Re: fsyncing directories

Or is this just a bug in IO::Handle?

Mostly yes, IO::Handle::sync requires a file handle open with write access.

The following workaround may work:

use IO::Handle;
sysopen my $dh, "/etc/", 0 or die "unable to open dir";
open my $dh1, ">&", $dh or die "unable to dup handle";
$dh1->sync or die "dir sync failed";
[download]

Comment on Re: fsyncing directories Select or Download Code

Replies are listed 'Best First'.
Re^2: fsyncing directories by betterworld (Curate) on Apr 27, 2010 at 13:26 UTC
Thank you, this is a nice workaround :) IO::Handle accepts this file handle because it thinks that it is opened for writing. From the strace output it seems that this does in fact fsync the directory. Excerpt: `open("/etc/", O_RDONLY) = 3 dup(3) = 4 fsync(4) = 0` [download] I don't think the dup() hurts the functionality. Though of course I cannot be sure because I'd have to crash my system repeatedly to see if the effect is the same.	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: fsyncing directories
by betterworld (Curate) on Apr 27, 2010 at 13:26 UTC

Thank you, this is a nice workaround :) IO::Handle accepts this file handle because it thinks that it is opened for writing.

From the strace output it seems that this does in fact fsync the directory. Excerpt:

open("/etc/", O_RDONLY)                 = 3
dup(3)                                  = 4
fsync(4)                                = 0
[download]

I don't think the dup() hurts the functionality. Though of course I cannot be sure because I'd have to crash my system repeatedly to see if the effect is the same.

[reply]
[d/l]