Paul Eggert <[EMAIL PROTECTED]> wrote: > "Matthew Woehlke" <[EMAIL PROTECTED]> writes: >> "shred" is sort-of in the same boat due to lacking fsync() > > I don't recall that problem but it is easy enough to fix. Here's > a patch. > > 2006-12-19 Paul Eggert <[EMAIL PROTECTED]> > > * m4/jm-macros.m4 (coreutils_MACROS): Check for fsync. > * src/dd.c (fsync) [! HAVE_FSYNC]: Define. > (dd_copy): Fall back on sync if fsync isn't available. > * src/shred.c (dosync) [! HAVE_FSYNC]: Likewise. > * src/dd.c (dd_copy): Check for EINTR from fdatasync, for > consistency with fsync.
Thanks, but I'd prefer to skip this change, unless there is a reasonably modern portability target that lacks the fsync function. I think of this as an opportunity to avoid adding infrastructure (and #ifdefs) that may never be used :-) We know how hard it is to remove such bits once they've been added. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
