On Wed, May 7, 2014 at 10:36 AM, Sylvestre Gallon <[email protected]> wrote:
> On Mon, May 05, 2014 at 08:40:10PM +0800, Helg wrote:
>> This patch fixes a bug where fusefs_link does not return an error on
>> subsequent invocations if a fuse filesystem does not implement hard
>> links.
>>
>> As an aside, returning ENOSYS in this case is contrary to the link(2)
>> man page (and different again to the Open Group) but consistent with
>> the fuse implementation on Linux.
>>
>> --
>> Helg <[email protected]>
>>
>>
>> Index: fuse_vnops.c
>> ===================================================================
>> RCS file: /cvs/src/sys/miscfs/fuse/fuse_vnops.c,v
>> retrieving revision 1.16
>> diff -u -p -r1.16 fuse_vnops.c
>> --- fuse_vnops.c        18 Mar 2014 08:51:53 -0000      1.16
>> +++ fuse_vnops.c        4 May 2014 06:32:50 -0000
>> @@ -540,8 +540,10 @@ fusefs_link(void *v)
>>         dip = VTOI(dvp);
>>         fmp = (struct fusefs_mnt *)ip->ufs_ino.i_ump;
>>
>> -       if (!fmp->sess_init || (fmp->undef_op & UNDEF_LINK))
>> +       if (!fmp->sess_init || (fmp->undef_op & UNDEF_LINK)) {
>> +               error = ENOSYS;
>>                 goto out1;
>> +       }
>>
>>         fbuf = fb_setup(cnp->cn_namelen + 1, dip->ufs_ino.i_number,
>>             FBT_LINK, p);
>>
>
> Hi,
>
> Thanks for your diff. Here is an updated version that adds some
> consistency on fuse error handling. We need to return ENXIO when
> the fuse communication channel is broken and ENOSYS when the libfuse
> callback does not exist.
>
> I've also modified some vnops to be sure that the checks for active
> fuse communication channel and for libfuse callbacks presence are
> done first...
>
> Any OK ?
>
> Cheers,

Anyone ?

-- 
Sylvestre Gallon

Reply via email to