Hi,
I am new to this forum, I came via my interest in GhostBSD since it has several features I am looking for in an OS, like running from RAM out of the box with easy customization. One of these features is OpenZFS, of course.
In 2024 OpenZFS enabled support for 1023 byte file names (https://github.com/openzfs/zfs/issues/13043).
I won't go into great lengths about the benefits of greater file names, to name a few, non-English languages get a much better support that way, getting close to equalizing users' ability to have long file names across encodings/localizations/languages. Surprisingly, Windows is still outperforming almost all operating systems in terms of file name length support for other encodings. Longer file names also allow to store more information in the file name, something very useful in certain cases (in my case for example, I really like to have all information about a book stored in its name and often this exceeds 255 character limit, and also sometimes it exceeds the 1024 byte file path limit...). Generally, it boosts users' freedom and ability to use their files however they'd wish, and I see no good reason to keep the outdated 255 byte limit.
I was really happy when I learned about the OpenZFS innovation, but it looks like FreeBSD still has 255 byte file name length. As I understand, the file length limit is determined by the NAME_MAX in /usr/src/sys/sys/syslimits.h file and it hasn't been changed in 3 years (https://github.com/freebsd/freebsd-src/blob/main/sys/sys/syslimits.h) and this can't be easily changed by a user as the change requires recompiling the kernel. Is there a significant reason to not implement longer filenames beside compatibility with other operating systems? FreeBSD could lead the way here, just like it did when it adopted OpenZFS.
It seems that there was a filename length discussion in 2017 on the FreeBSD mailing list with some enthusiasim, but it didn't catch on back then:
I wanted to post this in the Ideas Page, but looks like I am too new here for that.
Thank you for your attention
I am new to this forum, I came via my interest in GhostBSD since it has several features I am looking for in an OS, like running from RAM out of the box with easy customization. One of these features is OpenZFS, of course.
In 2024 OpenZFS enabled support for 1023 byte file names (https://github.com/openzfs/zfs/issues/13043).
I won't go into great lengths about the benefits of greater file names, to name a few, non-English languages get a much better support that way, getting close to equalizing users' ability to have long file names across encodings/localizations/languages. Surprisingly, Windows is still outperforming almost all operating systems in terms of file name length support for other encodings. Longer file names also allow to store more information in the file name, something very useful in certain cases (in my case for example, I really like to have all information about a book stored in its name and often this exceeds 255 character limit, and also sometimes it exceeds the 1024 byte file path limit...). Generally, it boosts users' freedom and ability to use their files however they'd wish, and I see no good reason to keep the outdated 255 byte limit.
I was really happy when I learned about the OpenZFS innovation, but it looks like FreeBSD still has 255 byte file name length. As I understand, the file length limit is determined by the NAME_MAX in /usr/src/sys/sys/syslimits.h file and it hasn't been changed in 3 years (https://github.com/freebsd/freebsd-src/blob/main/sys/sys/syslimits.h) and this can't be easily changed by a user as the change requires recompiling the kernel. Is there a significant reason to not implement longer filenames beside compatibility with other operating systems? FreeBSD could lead the way here, just like it did when it adopted OpenZFS.
It seems that there was a filename length discussion in 2017 on the FreeBSD mailing list with some enthusiasim, but it didn't catch on back then:
I wanted to post this in the Ideas Page, but looks like I am too new here for that.
Thank you for your attention
