![系统崩溃后在 NAS 服务器上重建 8.3 版的长文件名 (LFN)](https://linux22.com/image/1502394/%E7%B3%BB%E7%BB%9F%E5%B4%A9%E6%BA%83%E5%90%8E%E5%9C%A8%20NAS%20%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8A%E9%87%8D%E5%BB%BA%208.3%20%E7%89%88%E7%9A%84%E9%95%BF%E6%96%87%E4%BB%B6%E5%90%8D%20(LFN).png)
我的 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)“My Book”Essential 2TB NAS
主要的麻烦在于 Linux Gnome Evolution 电子邮件客户端的数千个本地电子邮件文件夹和消息。我在 WD FAT32 USB SSD(固态硬盘)上有一个单独的旧备份,它保留了文件夹的 LFN,但那里的消息要旧得多。尝试复制较新的备份(8.3)文件只会忽略较旧的 LFN 文件并保存为 8.3,从而重复内容。
我没有保存自崩溃以来,SSD 或 NAS 中没有任何文件,因此无法想象它们的内容实际上已被更改,而是怀疑我的新配置无法正确读取它们。
我们将根分区(/)重新格式化为文件系统和数据分区西弗斯按照操作系统的建议(openSUSE Leap 42.1)在重建过程中。数据分区是LUKS 加密。根分区和数据分区最初是扩展4。希望 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限制,这当然可以解释问题。但在崩溃之前这不是问题,所以我想知道为什么现在会出现问题?
另一方面
{en.wikipedia.org/wiki/Comparison_of_file_systems}(是的,我知道这不是一个合适的技术参考,但无论如何都很有用>:-)
重复 getconfNAME_MAX限制以上,并表示文件系统和XLS文件系统没有PATH_MAX限制。
再次,这些问题在崩溃之前并不存在,参数是相同的,所以我很难理解文件系统的变化是罪魁祸首。
我了解到康维{www.j3e.de/linux/convmv/man/}。听起来很有希望,但显然没用,因为 8.3 和 LFN 似乎都是 UTF8 文件名。我还没有找到任何地方为这两种名称格式提供明确的编码。
我认为我应该考虑山选项,但是哪个?
我使用的挂载命令是
mount -t cifs -o guest //192.168.5.1/"我的书" /mnt/NAS
在这一切发生之前,这很有效。正如我们所知道的山和星星一样数得过来……:-(
据我了解,这会将驱动器安装为 NFS 驱动器。看到 8.3 文件名与网易云音乐上面的引文是:
短名称出现在仅支持 8.3 格式的客户端上。短名称对 NFS 客户端不可见。
这些确实看起来像是 NFS 客户端,所以应该不是参见 8.3。非常奇怪。
因此我们检查山详细地:
{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安装指南以了解如何安装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 运行,并将 NAS 挂载为 chown安迪:用户但文件仍然显示为 8.3。
尝试 FAT检查=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 的。所以它一定是山或者文件系统属性问题。
再次感谢,安迪