That's fine.
Alle giovedì 25 ottobre 2012, Roland McGrath ha scritto:
> 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. If anything, we'd translate that to EGRATUITOUS in the
> general case, and perhaps to E
> AIUI, POSIX says there can be other, implementation-defined errors.
That's true. But when POSIX specifies a particular error code for a
particular condition, then you must yield the specified error code for that
situation. If this is arising for something like using a file-oriented
call on an
Richard Braun, le Fri 26 Oct 2012 19:15:02 +0200, a écrit :
> On Fri, Oct 26, 2012 at 07:07:02PM +0200, Samuel Thibault wrote:
> > Oh? I wonder how that produces MIG_BAD_ID: libtrivfs (used by pflocal)
> > is supposed to be returning EOPNOTSUPP when there is no underlying node,
> > which should be
On Fri, Oct 26, 2012 at 07:07:02PM +0200, Samuel Thibault wrote:
> Oh? I wonder how that produces MIG_BAD_ID: libtrivfs (used by pflocal)
> is supposed to be returning EOPNOTSUPP when there is no underlying node,
> which should be the case here.
Not really, as pflocal uses libtrivfs only for its
Pino Toscano, le Fri 26 Oct 2012 18:30:39 +0200, a écrit :
> Alle venerdì 26 ottobre 2012, Samuel Thibault ha scritto:
> > 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
Alle venerdì 26 ottobre 2012, Samuel Thibault ha scritto:
> 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. Th
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 fo
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 c
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?
Samuel
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.
If anything, we'd translate that to EGRATUITOUS in the general case, and
perhaps to EOPNOTSUPP in particular cases where it's not an ironclad part
of
Alle mercoledì 29 agosto 2012, Pino Toscano ha scritto:
> Hurd's implementations of fdatasync and fsync do not take into
> account the fact that file_sync could not be implemented in the
> receiving port, or implemented as stub, returning (E)MIG_BAD_ID or
> EOPNOTSUPP. Attached there is a patch to
Hi,
Hurd's implementations of fdatasync and fsync do not take into account
the fact that file_sync could not be implemented in the receiving port,
or implemented as stub, returning (E)MIG_BAD_ID or EOPNOTSUPP.
Attached there is a patch to normalize them to EINVAL, as specified by
POSIX.
Thanks
13 matches
Mail list logo
