Re: gnucash 2.2.6-2: please allow into testing

[Thomas Bushnell BSG <tb@becket.net>]

On Fri, 2008-09-12 at 00:48 -0700, Steve Langasek wrote:
> FWIW, I know there have been other cases in the past where glibc has handled
> ENOSYS returns for unimplemented syscalls and fallen back to older,
> less-preferred interfaces to avoid returning ENOSYS to the caller for a case
> where the ENOSYS is an implementation detail between glibc and the kernel.
> I can see that this isn't completely analogous to the sshfs case, though,
> since link isn't exactly a new syscall...  So if this should be regarded as
> an sshfs bug, that's fine with me.

That's right.  ENOSYS means something *very* specific.  It doesn't mean
"unimplemented in this case", it means, "unimplemented period."  The
kernel should never return ENOSYS to mean "unimplemented in this case".

That doesn't mean that the kernel should map sshfs ENOSYS into something
else.  That is a matter for the interface between the kernel and the
filesystem; no standard addresses that.  But on the other hand, the
kernel's defined interface seems to be to return the underlying
filesystem's errors without modification, and it's sshfs's responsiblity
to conform to that interface.  Thus, sshfs should return EPERM.

If the kernel wanted a different interface, where filesystems could
return ENOSYS in response to link calls, and the kernel mapped those
into EPERM, I suppose it would be ok, but I see no reason for preferring
it--it's less clear and less obvious what's going on--and it isn't
sshfs's job to dictate to the kernel what the interface ought to be
anyhow.

Thomas