The <linux/limits.h> defines NAME_MAX as 255 (_not_ including nul) and
PATH_MAX as 4096 (including nul). It would be nice to keep this
convention also on the FUSE side; that is, define FUSE_NAME_MAX as
1023, or in your case (3 * 1024 - 1). I think this is the also
intention of the code in fuse_notify_inval_entry:
err = -ENAMETOOLONG
if (outarg.namelen > FUSE_NAME_MAX)
goto err;
Otherwise, we should fix this check as well (outarg.namelen >=
FUSE_NAME_MAX). That said, keep in mind that using dir-entry names
larger then NAME_MAX would also cause ENAMETOOLONG by glibc’s
readdir[1]
- Shachar.
[1] https://github.com/bminor/glibc/blob/master/sysdeps/unix/sysv/linux/readdir_r.c#L52-L59
On Thu, Dec 12, 2024 at 11:51 PM Bernd Schubert <bschubert@xxxxxxx> wrote:
>
> Our file system has a translation capability for S3-to-posix.
> The current value of 1kiB is enough to cover S3 keys, but
> does not allow encoding of escape characters. The limit is
> increased by factor 3 to allow worst case encoding with %xx.
>
> Testing large file names was hard with libfuse/example file systems,
> so I created a new memfs that does not have a 255 file name length
> limitation.
> https://github.com/libfuse/libfuse/pull/1077
>
> Signed-off-by: Bernd Schubert <bschubert@xxxxxxx>
> ---
> fs/fuse/fuse_i.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
> index 74744c6f286003251564d1235f4d2ca8654d661b..91b4cdd60fd4fe4ca5c3b8f2c9e5999c69d40690 100644
> --- a/fs/fuse/fuse_i.h
> +++ b/fs/fuse/fuse_i.h
> @@ -39,7 +39,7 @@
> #define FUSE_NOWRITE INT_MIN
>
> /** It could be as large as PATH_MAX, but would that have any uses? */
> -#define FUSE_NAME_MAX 1024
> +#define FUSE_NAME_MAX (3 * 1024)
>
> /** Number of dentries for each connection in the control filesystem */
> #define FUSE_CTL_NUM_DENTRIES 5
>
> --
> 2.43.0
>
>
