Re: New packages and cross-config.gnu
> Roland McGrath <roland@frob.com> writes:
>
> > Actually it's not fully backward compatible. As I was just reminded, the
> > libc `sync' function, which is what the fileutils sync uses (sync is in
> > fileutils, not sh-utils), is backward-compatible and thus not synchronous
> > (it passes a zero wait flag in file_syncfs).
>
> Hmm. Hurd sync should use the libc sync function too; it should not
> set the wait flag. If it does, that's a bug.
It must be a confusing feature, because the code was written by the
infamous Michael I. Bushnell (may he rest in peace), who did not write bugs.
> The default should be nowait, with an option (--synchronous comes to
> mind) to request synchronous sync.
I changed the default for utils/syncfs, so I think it now matches what you
would like the hurd sync to be (except in name).
> I'd rather GNU be a nice system, than try and separate out naturally
> joined functionality. sync, on GNU, should be responsible for sync,
> in all its various flavors. On linux only one kind of sync is
> possible, but that's not important to us; fileutils sync is GNU sync,
> not just Unix sync, and we should not hesitate to have it do better
> and more clever stuff on the Hurd.
>
> I think having a more generic syncfs libc function as you describe is
> a good idea; then fileutils could use that in a suitably generic
> fashion.
Yes, that is all fine, unless libc or fileutils maintainers object.
fileutils can use autoconf checks for syncfs. I don't have time to do that
now. Also, I noticed the libc manual's description of sync is wrong (says
its synchronous). That should be fixed (as well as documenting syncfs).
The manual says X/Open specifies sync; it might be worth someone checking
to see if it mis-specifies it too, just so we can mention it in some
documentation.
Reply to: