Will FreeBSD follow OpenZFS' lead and embrace longer file names?

[BSDsEnjoyer]

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:

extending the maximum filename length

I wanted to post this in the Ideas Page, but looks like I am too new here for that.

Thank you for your attention

 

[SirDice]

discussion in 2017 on the FreeBSD mailing list

FreeBSD switched to OpenZFS with 13.0-RELEASE (April 2021).

FreeBSD 15.1 has OpenZFS 2.4.2

# zfs -V
zfs-2.4.2-1-FreeBSD_g6330a45b0
zfs-kmod-2.4.2-1-FreeBSD_g6330a45b0

I wanted to post this in the Ideas Page

Which ideas page? On the FreeBSD wiki?

but looks like I am too new here for that.

Your account here gives you access to the forums and only the forums. It's not linked to any other FreeBSD website.

 

[BSDsEnjoyer]

FreeBSD switched to OpenZFS with 13.0-RELEASE (April 2021).​

Oh, I didn't know that, I was under impression that it was with OpenZFS for longer.

FreeBSD 15.1 has OpenZFS 2.4.2​

Then FreeBSD can have longer filenames without problems with OpenZFS, it just needs different kernel settings (different
NAME_MAX in /usr/src/sys/sys/syslimits.h file), as I understand.

If I'd try to create a file with a long name in FreeBSD, for example:

echo book > '7873421, Commentaria in Aristotelem Graeca edita consilio et auctoritate academiae litterarum Regiae Borussicae, Greek Commentaries on Aristotle edited by order and authority of the Prussian Royal Academy of literary studies, Voluminis V Pars V Themistii in Aristotelis Metaphysicorum librum Λ paraphrasis hebraice et latine, Volume 5 Part 5 Themistius' Paraphrase of Aristotle's Metaphysics Book 12 in Hebrew and Latin, Themistius, Samuel Landauer, Berlin, 1903, fffe14e37f5c6c0b90325567378ae2a2e8b8e0a1e11cc314f053152b859bc4cb'

(the book names I'd want can even be nearly 2x longer or even longer but these won't be supported by current OpenZFS version)

I would get an error that the file name is too long. But OpenZFS should support such file lengths, so FreeBSD's current settings are the bottleneck.

Which ideas page? On the FreeBSD wiki?​

Yeah, but this thread might suffice

 

[cracauer@]

PATH_MAX is still 4K.

So just the filename longer doesn't buy you much if you also use such length for directory names.

 

[BSDsEnjoyer]

PATH_MAX is still 4K.

Definitely! Thanks for replying! The directory structure can be kept short, so NAME_MAX increase would give much, much more freedom to name files as a user would wish. Also, I think that OpenZFS has no limit for path lengths, so if PATH_MAX could be increased as well, that would be wonderful!

 

[kent_dorfman766]

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've been grinding my teeth trying to avoid responding but I guess I'm weak so I'll "with respect" vehemently disagree with the above position. A filename is like a book/essay/report title. It is NOT suppose to contain a detailed description of the content. That's what metadata files are for. Furthermore, ask anyone who has had to deal with undisciplined office workers naming their files any old thing they want...It is simply a PITA! When asked to follow naming conventions your typical office worker pretty much ignores the wishes of the data processing folks...but then they have no problem at all asking/demanding those same data processing people to sort/sift/organize/search countless meaninglessly named files for information.

I have several rules regarding filenames:

1. all filenames will contain ISO-8859-1(latin-1) character set only
2. filenames must not contain any special characters nor characters that must be escaped when entered in the shell
3. date/time information in the filename MUST follow a sortable ISO format like 2026-01-12_21:03:00Z
4. filename must be concise, relevant, and meaningfully sortable in the context of similarly named files in that directory

This post just comes across as another "hey, let's bring BSD to the masses" plug, when in fact OP will find that many/most of us BSD power users don't want BSD to move into that domain because technical excellence will suffer tremendously...FreeBSD is an expert system for experts. Let's keep it that way.

 

[freethread]

I have something to add about this too. I've been using DOS/Windows for a long time, even before long filenames were added. The length of 8.3 names bothered me a bit, but I've never used names longer than 100-150 characters, and very rarely, the normality was about 15-20 charaters long. Above all, I've always followed the rules kent_dorfman766 outlined, and I've never used spaces to separate words (undrscores or camel case under Unix, NT and derived). So I agree with maintaining certain limits. 4k is over my limits.

 

[hedwards]

PATH_MAX is still 4K.

So just the filename longer doesn't buy you much if you also use such length for directory names.

I've personally had more issues with that limitation on various FSes over the years than the name length of files. For the most part longer file names just get unwieldy before you tend to hit the limit on how many characters you can use, but depending upon what you're doing, certain directories have to be right near the root directory or you'll run out of space for stuff inside of it. I've had that happen the most when trying to extract other people's source code into my home directory.

 

[BSDsEnjoyer]

kent_dorfman766 Thank you for sharing your concerns! Here are some of my thoughts regarding your post:

A filename is like a book/essay/report title. It is NOT suppose to contain a detailed description of the content. That's what metadata files are for ... I have several rules regarding filenames:

There are many use cases for a filesystem to have long file names, and greater name lengths have been introduced to OpenZFS for good reasons - otherwise the professionals developing OpenZFS would not have done that. If your use case does not need longer file names, simply don't use them, it won't be hard for a sysadmin to place some stops for file name lengths. For example, any file additions can be shortened or brought to a proper standard with scripts. Generally, this can be solved within an organization, while many other organizations would benefit greatly from longer file names. I personally suffer greatly when transferring large amounts of data from NTFS to UNIX-like systems pretty often because the file name length in certain cases on NTFS is better (longer).

That's what metadata files are for

If your work flow works well with metadata files and everything is fine, I don't see how a file name length increase would hurt your use case considerably. It is also very much possible that combining a "raw name" and some information about a file in the name (in other words, having a longer name with needed information) might work out for a lot of scenarios.

Furthermore, ask anyone who has had to deal with undisciplined office workers naming their files any old thing they want...It is simply a PITA!

I really don't think that such a problem really applies here. You describe a specific case and this is a problem existing right now anyway, so I don't think that extending file names would really add much to this "undisciplined office workers" problem.

This post just comes across as another "hey, let's bring BSD to the masses" plug, when in fact OP will find that many/most of us BSD power users don't want BSD to move into that domain because technical excellence will suffer tremendously...FreeBSD is an expert system for experts. Let's keep it that way.

I've created this post because I believe that there is an objective need to extend FreeBSD's functionality and, to repeat myself, the file name length was increased in OpenZFS for good reasons, thus FreeBSD is staying behind in integrating this innovation. If your perfect file name length is, for example, lower than 64 bytes, freedom to have 255 byte length names already exists and does not hurt technical excellence, so a further file name length increase would not fundamentally change this while allowing more use cases and improving some existing use cases. I believe that at the minimum an option of utilizing longer file names should exist which would not require recompiling the kernel. There is no way this would hurt the technical excellence of the base system whatsoever.

The length of 8.3 names bothered me a bit, but I've never used names longer than 100-150 characters.

freethread thanks for replying to this thread! Of course, many people and sysadmins (also people!) are ok with short file names. That experience, however, cannot imply a perfect universal use case.