-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Thomas,

Thomas Bushnell BSG wrote:
> But also, there is most certainly an sshfs bug here.  It has no business
> whatsoever returning ENOSYS in response to a link call.

I tried to figure out who is doing wrong here. If at all it's the fault
of fuse, who sets the default return code ENOSYS for all unset (i.e.
unimplemented) function pointers in fuse_operations -- the sshfs simply
does not implement a link() function.

A different error code for link() wouldn't be that a big deal: If I
understand the fuse code correctly it is sufficient to check for an
ENOSYS in kernel/dir.c at the end of the fuse_link() function and
replace it by the desired one. But...

> There are far better error codes to return.

... what error codes listed in the link(2) manpage do you think of?
The best one that comes to my mind is EPERM: "The filesystem containing
oldpath and newpath does not support the creation of hard links."

But, sorry, I will stop here. If you think this should be reported to
the fuse package, go ahead, clone this bug and reassign the cloned bug
to fuse. For now I'm just comfortable with having a fix for Gnucash.

Regards
  Micha
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFItxsXWN0/4pnhQbQRAhY6AJ92dljsm6JCOvowVhZwK2ReeBDG8QCg4zUd
32oBx9qb5bI28AP+rVow0WU=
=7Caw
-----END PGP SIGNATURE-----



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to