[Top][All Lists]

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

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

From: Samuel Thibault
Subject: Re: [PATCH.HURD] fix fdatasync/fsync if file_sync is not supported
Date: Fri, 26 Oct 2012 16:59:54 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]