lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <63C71AFEB9EEBDC8+20251210145935.72a6f028@winn-pc>
Date: Wed, 10 Dec 2025 15:02:11 +0800
From: Winston Wen <wentao@...ontech.com>
To: linux-ext4@...r.kernel.org
Subject: Inquiry: Possible built-in support for longer filenames in ext4
 (beyond 256 bytes)

Hello ext4 maintainers and community,

I am writing to seek your advice on a potential enhancement regarding
filename length support in ext4.

Currently, ext4 supports filenames up to 255 bytes, which is sufficient
for most use cases. However, in cross-platform scenarios, particularly
when migrating directories from Windows to Linux, we encounter issues
with filenames that exceed this limit. Windows allows filenames longer
than 256 bytes (including multi-byte characters such as Chinese), which
can lead to filename overflow when copying such files to ext4.

We are aware that workarounds like wrapfs can be used to support longer
filenames, but in practice, this approach is not ideal for seamless
user experience. We are therefore curious whether it would be feasible
to implement built-in support for longer filenames in ext4 itself.

One idea we considered is using extended attributes (xattr) to map long
filenames, or perhaps another mechanism that would allow storing and
accessing filenames beyond the current limit without breaking existing
compatibility. However, we are not experts in this area and would
appreciate guidance from the community.

Could you share your thoughts on:

- Whether there is interest in supporting longer filenames in ext4
natively.
- Possible implementation approaches (e.g., xattr-based mapping,
on-disk format extensions, etc.).
- Any prior discussions or attempts in this direction that we might
have missed.

If there is a feasible path forward, we are willing to research the
issue in depth and attempt to implement an RFC patch for community
review. We would greatly appreciate your guidance on where to start and
what the key considerations would be.

Thank you for your time and insights.

-- 
Thanks,
Winston


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ