> Roland McGrath <[EMAIL PROTECTED]> 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.
