On 12/13/24 10:17, Shachar Sharon wrote: > [You don't often get email from synarete@xxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > 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; Thanks for the review, I can change it to (3 * 1024 - 1) or (PATH_MAX - 1). > > 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 Yes, I had seen that glibc uses NAME_MAX, but I had also tested the patch using the new memfs [1] and the attached script. You can try it out yourself - listing long file names actually works (on a Debian 12 system). Thanks, Bernd [1] https://github.com/libfuse/libfuse/blob/master/example/memfs_ll.cc
Attachment:
long-file-name.sh
Description: long-file-name.sh
