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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
