Bug 16491 - tmpfs doesn't support files with filenames longer than 255 bytes
Summary: tmpfs doesn't support files with filenames longer than 255 bytes
Status: RESOLVED WILL_NOT_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: fs_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-01 21:35 UTC by Artem S. Tashkinov
Modified: 2010-09-16 18:49 UTC (History)
1 user (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Artem S. Tashkinov 2010-08-01 21:35:58 UTC
touch: cannot touch `1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111': File name too long

That is especially relevant when you try to copy some files from a remote NTFS/cifs filesystem.
Comment 1 Hugh Dickins 2010-09-16 07:16:24 UTC
I'm puzzled as to why you raise this as a bug on tmpfs: I'm having
difficulty finding a Linux filesystem with a greater limit on filename
length than 255 (NAME_MAX).  Isn't that the limit on ext2, ext3, ext4,
btrfs, reiserfs, ramfs, ... even the Linux ntfs?

I notice the Linux cifs does claim f_namelen PATH_MAX; but tmpfs will
cause far less trouble if it remains consistent with all the other
Linux filesystems mentioned above, than if it were to allow a longer
filename than any of them.

Or am I misunderstanding?
Comment 2 Hugh Dickins 2010-09-16 18:34:04 UTC
On Thu, 16 Sep 2010, Artem S. Tashkinov wrote:

> No, at least NTFS partitions (255 UTF-16 code units, thus it can hold e.g.
> 255 non ASCII symbols, which in UTF-8 translates to 255x2 bytes) can have
> these long file names even under Linux and FAT32 can have up to 255 OEM
> chars, so e.g. for CP866 translated to UTF8 that means up to 255x2 bytes
> either,

Ah yes, I believe you're right: although the Linux ntfs statfs(2) advertizes
a limit of 255 bytes, the practical limit enforced is actually higher.

> but then maybe you right, if Linux strives to be incompatible with existing
> technologies and implementations in the Windows world, there's nothing else
> we can do about it.
> 
> I just thought that maybe in TMPFS a support for longer filenames could have
> been added, since TMPFS is easy to hack, because it doesn't have a hard
> storage.

You're right that the lack of persistent storage makes tmpfs much easier
to hack, I hadn't been looking at your request that way.

But even so, tmpfs is not the filesystem people look to, to set a lead in
this way.  If longer filenames are wanted, it's in ext4 and btrfs that they
should first be implemented: both are recent filesystems under active
development, both have elected a max filename of 255 bytes.

If you can persuade Ted Tso and Chris Mason and linux-fsdevel to implement
longer filenames to suit Windows, then I'll gladly raise the tmpfs maximum
to match; but until then, I'd rather keep the public tmpfs compatible with
ext4 and btrfs and the rest (I missed xfs before, but it too is the same).

You are, of course, welcome to hack your own tmpfs: ignoring what statfs()
advertizes, I presume it would amount to nothing more than hacking the
NAME_MAX in simple_lookup() in fs/libfs.c (which would also give you long
names in ramfs and hugetlbfs etc.).

But then you'll quickly come up against the PATH_MAX 4096 limit?

> 
> If you think it's not feasible and is not worth the trouble, I will close the
> bug report as WONTFIX.

I think it's feasible, but ill-advised to make tmpfs diverge from all
the others: I don't want to be involved in all the bugreports of how
this tmpfs file could not then be copied to another filesystem.

So, until the others are extended, please do close this as WONTFIX.

Thanks,
Hugh
Comment 3 Artem S. Tashkinov 2010-09-16 18:49:31 UTC
OK, I'll bring up the discussion in LKML later.

Note You need to log in before you can comment on or make changes to this bug.