[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Reply to: