This list has been deprecated. Please subscribe to the new devel list at
lists.nfs-ganesha.org.
knfsd seems to send EINVAL based on a quick look at the code. Assuming it
as end of file (0) may work, but will have to check if all cthon tests pass!
On Wed, Apr 25, 2018 at 4:26 AM, Frank Filz <ffilz...@mindspring.com> wrote:
> In NFS v4 and NLM, the lock length type is uint64_t. In many of our
> supported filesystems, lock length is defined as off_t or off64_t which are
> signed quantities.
>
>
>
> The Windows NFS v3 client at least has demonstrated issuing a lock length
> of UINT64_MAX.
>
>
>
> FSAL_GPFS returns an error if lock length is greater than LONG_MAX.
>
>
>
> FSAL_GLUSTER and FSAL_VFS stuff the value into an off64_t, and then
> complains about lock length being less than zero.
>
>
>
> I’m not sure about the other FSALs.
>
>
>
> Returning an error ends up making Windows applications not work which is
> not ideal.
>
>
>
> I think it might be best if inside the FSAL, we just quietly reduce lock
> length to a valid value, though I don’t know if that should be:
>
>
>
> 0 – indicating end of file
>
> INT64_MAX – largest possible length
>
> INT64_MAX – offset – so end of lock doesn’t exceed INT64_MAX
>
> Does anyone have any thoughts?
>
>
>
> Frank
>
> _______________________________________________
> Devel mailing list -- de...@lists.nfs-ganesha.org
> To unsubscribe send an email to devel-le...@lists.nfs-ganesha.org
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
