This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH.HURD] fix fdatasync/fsync if file_sync is not supported
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Pino Toscano <toscano dot pino at tiscali dot it>
- Cc: libc-alpha at sourceware dot org, bug-hurd at gnu dot org
- Date: Thu, 25 Oct 2012 09:49:51 -0700 (PDT)
- Subject: Re: [PATCH.HURD] fix fdatasync/fsync if file_sync is not supported
- References: <201208292133.18124.toscano.pino@tiscali.it>
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 the interface contract that it implement the particular protocol. So I
think we should separate the MIG_BAD_ID case and treat it more generally,
if at all.
Since it's the norm for servers to return EOPNOTSUPP for miscellaneous RPCs
they aren't implementing, translating that to EINVAL for fsync/fdatasync is
reasonable. It should have a comment saying that POSIX.1 specifies EINVAL
for a file descriptor on which sync is not supported.
Thanks,
Roland