File path limits

[choin]

First, sorry if it seems like here is a wrong place for such a thread, but from what I see it seems the only fitting place. But I'm new to forums so please correct me if necessary.

 

I'm a Windows user but have been hearing great stuff about Linux and its derivatives, and would like these systems and communities to thrive as much as possible.

I'm new to NAS. Have been using a collection of external HDD for years, but recently decided to build NAS with Unraid.

 

Upon my first day of trying to use the system, I discovered the following issue:

The file name you specified is not valid or too long

This is a notorious error message in Windows that indicates that the full file path is too long to be handled.

 

Most people here surely understand what the issue is about. But after some research, I conclude that this issue is not being discussed enough. See, I've been using external drives over the years, and of course I've been aware of the issue with long file paths - ones over 255 symbols. I know Windows 10 introduced the famous "NTFS long paths" tweak. But I never used Windows 10. For most of the time I've used Windows 7/8 (it's Windows 11 since recently). All my library is already within the "255" limitation - or so I thought.

 

But wait, NAS is seen as an SMB share by Windows, right? And drives in NAS are not using NTFS, right? Yes. But there is more to that, from what I see. My conclusions after doing some research is the following:

- Unraid has limitations of 255 bytes for file paths.

- The original limitation for NTFS is a 255 symbols. Not 255 bytes. This could mean anywhere between 512 or 1024 bytes if I understand it correctly.

 

I've seen some discussions mentioning this as the limitation of Samba in Linux. But this also raises concerns:

- SMB share made and handled by Windows can support up to 255 symbols fine.

- All 4 file systems currently supported by Unraid seem to have 255 bytes limitation. This suggests Samba might not be the cause.

- It seems Linux is in some disadvantage, and I can't understand why this issue is not getting enough attention.

 

I could write scripts to rename parts of my library containing long file paths. But:

- It'll take time I may not have.

- Trying to strings into a set length is a trivial problem. Trying to fit strings containing UTF-16 paths into a set amount of bytes is something else.

- Even after renaming, some parts of the library will be in a state very close to limit of the file system, which limits further actions to them.

- I could just archive folders with long paths but then I won't be able to index their contents in apps I use.

 

This might actually be a deal breaker for the whole idea of using NAS to me. I avoided Windows 10 for so many years. In 2024 I actually expected any current non-Windows system to handle long file paths. Dealing with 255 symbols limit is what I take for granted, but I have no idea what to do about the 255 bytes limit. Discovering a storage-oriented Linux system not supporting even 255 (UTF-16) symbols was unthinkable. I wish it was at least considered an issue.

 

Does anyone have recommendations or at least know good places to monitor related developments?

[choin]

It seems I was wrong about this part:

2 hours ago, choin said:

Unraid has limitations of 255 bytes for file paths

The limitation of 255 bytes is for file names, not full file paths.

This makes it much easier to me, perhaps manageable. But I still see it as an issue.

[choin]

From BTRFS docs: https://btrfs.readthedocs.io/en/latest/ch-fs-limits.html

Quote

 

maximum file name length

255

This limit is imposed by Linux VFS, the structures of BTRFS could store larger file names.