Re: [PATCH.HURD] fix fdatasync/fsync if file_sync is not supported

[Samuel Thibault]

Svante Signell, le Fri 26 Oct 2012 08:03:43 +0200, a écrit :
> On Thu, 2012-10-25 at 19:47 +0200, Samuel Thibault wrote:
> > Roland McGrath, le Thu 25 Oct 2012 09:49:51 -0700, a écrit :
> > > We don't generally handle MIG_BAD_ID.  That error indicates a server not
> > > implementing the protocol for which it's being used, which is a server 
> > > bug.
> > 
> > Pino, in which case did you actually get MIG_BAD_ID precisely?
> 
> compiling clisp and using a pipe
> to create the log file: dpkg-buildpackage -b 2>&1 | tee build.log failed
> while redirecting with dpkg-buildpackage -b > build.log 2>&1 worked.

Ok, so the issue here boils down to the application calling
fdatasync/fsync on stdout, which does make sense when the output is
redirected to a file, so the application is right in doing this call
(even if it's probably not right in going crazy if it doesn't return
EINVAL).

In the pipe case (i.e. pflocal), libtrivfs is used, EOPNOTSUPP is
returned, right? Do we have another case where MIG_BAD_ID is really
returned? i.e. a case where a translator which doesn't answer to the
file interface still appears in the file hierarchy?

Samuel