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
