Proposal to Increase Long Filename Limit Support

[narfa0215]

Currently, GitHub does not seem to provide an option for handling long filenames. It would be beneficial to add support for longer filenames, similar to how ZFS has implemented this feature. ZFS already provides an option to extend the filename length limit, enabling users to work with longer filenames. If this functionality could be added to GitHub, especially with file systems like Btrfs, it would greatly improve compatibility and flexibility when managing large or deeply nested files.

ZFS has successfully implemented this feature, and if Btrfs could implement something similar, it would further enhance cross-platform file management. Adding support for long filenames would resolve issues that arise when working with large files or complex file structures, ensuring a smoother experience for users.

For reference, here is the pull request for the ZFS implementation: OpenZFS PR #15921.

[kdave]

AFAIK the maximum file name length depends on the VFS in linux, where the limit is 255. The data structures in btrfs allow longer file names but without the generic layer support users could not use it. The linked PR says otherwise though, that the limit is not imposed by VFS, only the maximum path length must be PATH_MAX. Which seems to be correct.

However there could be a problem with compatibility in linux environment, because the system limit getconf NAME_MAX is 255, POSIX NAME_MAX as well. Increasing the limit on one filesystem brings problems when files are copied around. This should be probably discussed at the fsdevel mailinglist first, possibly with btrfs implementation so there's something to test.

Previous discussion (2009) https://lwn.net/Articles/331615/ "Long discussions about long names" is more about the FAT and patent problems, things have changed since because now we have proper EXFAT implementation.

[narfa0215]

AFAIK the maximum file name length depends on the VFS in linux, where the limit is 255. The data structures in btrfs allow longer file names but without the generic layer support users could not use it. The linked PR says otherwise though, that the limit is not imposed by VFS, only the maximum path length must be PATH_MAX. Which seems to be correct.

However there could be a problem with compatibility in linux environment, because the system limit getconf NAME_MAX is 255, POSIX NAME_MAX as well. Increasing the limit on one filesystem brings problems when files are copied around. This should be probably discussed at the fsdevel mailinglist first, possibly with btrfs implementation so there's something to test.

Previous discussion (2009) https://lwn.net/Articles/331615/ "Long discussions about long names" is more about the FAT and patent problems, things have changed since because now we have proper EXFAT implementation.

There have been similar attempts, and you can refer to this link: https://wiki.etersoft.ru/Linux/VLFN.

[kdave]

Thanks, the patch on the page seems to mix 3 things. One is the btrfs length which is technically correct but need to handle backward compatibility. Then it changes the UAPI limit, this would apply to all filesystems and can potentially break everything, if applications use that. Alternatively it's better to use the Namelen from stat -f. The compat_dirent change is for FAT only and some ioctls.

Anyway, I have a working patch for btrfs (with the incompat bit), the limit can be set up to 4095 bytes although this basically does not allow the full limit to be used because with / it will reach the PATH_MAX limit. So the next step is to discuss that at fsdevel.

[Forza-tng]

Could the extended length option be exposed via a mount option or similar? It would be similar to the long filename 'workaround' for Windows apps by using the \\?\ prefix. Though, it would be better to make a more universal for all fs Linux supports.

[kdave]

Do you mean to set the length via a mount option?

Otherwise, I think that NAME_MAX is used in many applications for static buffers and arguably it's kind of a linux ABI. Typically to include limits.h or define some fallback value and then expect any user supplied file name will fit. IOW a potential security problem. (https://codesearch.debian.net with \bNAME_MAX regex)

It would be possible to turn it on even after mount, eg. via sysfs. To enable it only per directory (as an attribute, there already is F for case insensitive lookup) won't work as the maximum file length is assumed for the whole filesystem by VFS.