我的FAT32 NAS丢失了它在多个目录中的长文件名。
它仅显示8.3文件名。
我应该如何找回LFN？
这是在主系统崩溃中发生的，该崩溃需要重新格式化并从备份中重建硬盘。我还没有接触过NAS，所以只能奇怪为什么我再也看不到LFN，只有8.3。
摘要：
1. NAS description
2. Problem
3. Actions subsequent to crash (none to the NAS)
4. File types: root—btrfs, data—XFS, formerly Ext4
5. PATH_MAX and NAME_MAX appear alright
6. convnv encoding is the same for 8.3 and LFN?
7. Numerous examinations of **man mount**
8. Parent app for files: Evolution email client
尽管下面详细讨论了几个小时，但我在这一点上仍然一无所知。在此过程中，我学到了很多有关文件系统和文件名的知识，但还没有解决方案。我将不胜感激。
最好的问候，安迪
=====
单位是
西部数据（WD）“我的书”必备2TB NAS
主要麻烦在于，Linux Gnome Evolution电子邮件客户端有数千个本地电子邮件文件夹和消息。我在WD FAT32 USB SSD（固态驱动器）上有一个单独的较旧备份，该备份保留了文件夹的LFN，但那里的消息要旧得多。尝试复制较新的备份（8.3）文件只会忽略较早的LFN文件，并另存为8.3，从而复制了内容。
自从崩溃以来，我还没有将任何文件保存到SSD或NAS中，所以无法想象它们的内容实际上已被更改，而是怀疑我的新配置未正确读取它们。
在重构过程中，根据操作系统的建议（openSUSE Leap 42.1），我们将根分区（/）重新格式化为btrfs，并将数据分区XFS重新格式化。数据分区经过LUKS加密。根分区和数据分区最初是Ext4。希望LFN不应依赖于Ext4？
主系统和NAS上的路径名和文件名限制分别为4096/255：
{} serverfault.com/questions/9546/filename-length-limits-on-linux
# getconf NAME_MAX /dev/sda3
255
# getconf PATH_MAX /dev/sda3
4096
然而
{} kb.netapp.com/support/index?page=content&id=3011981&actp=search&viewlocale=en_US&searchid=1452757427425
说路径长度包含在NAME_MAX限制中，这肯定可以解释问题。但这不是坠机前的问题，所以我想知道为什么会是现在？
OTOH
{en.wikipedia.org/wiki/Comparison_of_file_systems}（是的，我不知道适当的技术参考，但无论如何还是有用的：>-）
重复上面的getconf NAME_MAX限制，并说对于btrfs和XLS文件系统没有PATH_MAX限制。
同样，这些问题在崩溃之前不存在，参数相同，因此我很难理解文件系统更改是罪魁祸首。
我已经了解了convmv {www.j3e.de/linux/convmv/man/}。听起来很有希望，但似乎毫无用处，因为8.3和LFN都是UTF8文件名。我还没有找到为这两种名称格式提供明确编码的地方。
我看到我应该考虑安装选项，但是哪个呢？
我正在使用的mount命令是
mount -t cifs -o guest //192.168.5.1/“我的书” / mnt / NAS
在所有这一切发生之前，这工作正常。众所周知，安装选项与星星一样多... :-(
据我了解，这会将驱动器安装为NFS驱动器。看到8.3文件名与上面的kb.netapp.com引用矛盾，该引用表示：
短名称出现在仅支持8.3格式的客户端上。短名称对NFS客户端不可见。
这确实似乎是NFS客户端，因此应该不会看到8.3。很奇怪。
因此，我们详细研究了mount：
{} linux.die.net/man/8/mount
一些调查领域；以前没有使用过这些，我们可以将它们作为显式选项进行处理，以查看它们是否解决了问题：
cifs:
See the options section of the mount.cifs(8) man page
(cifs-utils package must be installed).
它被安装。
{} linux.die.net/man/8/mount.cifs
mount.cifs {service} {mount-point} [-o options]
mount.cifs //192.168.5.1/"My Book" /mnt/NAS -o guest,uid=1000,gid=100,rw
该文件由root运行，并以chown andy：users的身份挂载NAS，但文件仍显示为8.3。
尝试FAT check = r选项：
mount.cifs //192.168.5.1/"My Book" /mnt/NAS -o guest,uid=1000,gid=100,rw,check=r
但这是不允许的。
fat:
check=r
看起来好像check = s有效，不允许使用LFN。这已成为默认设置吗？
codepage=value
Sets the codepage for converting to shortname characters on FAT
and VFAT filesystems. By default, codepage 437 is used.
iocharset=value
Character set to use for converting between 8 bit characters and
16 bit Unicode characters. The default is iso8859-1. Long file-
names are stored on disk in Unicode format.
因此，我们尝试：
mount -t fat -o guest //192.168.5.1/"My Book" /mnt/NAS
但没有喜悦
vfat:
First of all, the mount options for fat are recognized.
The dotsOK option is explicitly killed by vfat. Furthermore, there are
没有什么看起来特别有用，并且
mount -t vfat -o guest //192.168.5.1/"My Book" /mnt/NAS
失败。
- 大部分8.3文件的父应用程序是Gnome Evolution电子邮件客户端。但是同样，这些是备份文件，而不是崩溃中丢失的实际数据文件。因此，它继续让我回避，原始的LFN如何神秘地变成8.3，而无需我直接采取任何行动。因此，它必须是安装或文件系统属性的问题。
再次感谢，安迪