-----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]