☰

系统崩溃后在 NAS 服务器上重建 8.3 版的长文件名 (LFN)

tag-icon • tag-icon filesystems fat32
系统崩溃后在 NAS 服务器上重建 8.3 版的长文件名 (LFN)

我的 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

尽管经过了下文详述的几个小时的仔细调查，但我仍然一无所知。在此过程中，我学到了很多关于文件系统和文件名的知识，但没有找到解决方案。我将不胜感激任何可能的帮助。

谨致问候，安迪

=====

  1. 单位是

    西部数据（WD）“My Book”Essential 2TB NAS

  2. 主要的麻烦在于 Linux Gnome Evolution 电子邮件客户端的数千个本地电子邮件文件夹和消息。我在 WD FAT32 USB SSD（固态硬盘）上有一个单独的旧备份，它保留了文件夹的 LFN，但那里的消息要旧得多。尝试复制较新的备份（8.3）文件只会忽略较旧的 LFN 文件并保存为 8.3，从而重复内容。

  3. 我没有保存自崩溃以来，SSD 或 NAS 中没有任何文件，因此无法想象它们的内容实际上已被更改，而是怀疑我的新配置无法正确读取它们。

  4. 我们将根分区（/）重新格式化为文件系统和数据分区西弗斯按照操作系统的建议（openSUSE Leap 42.1）在重建过程中。数据分区是LUKS 加密。根分区和数据分区最初是扩展4。希望 LFN 不依赖于 Ext4？

  5. 主系统和 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限制。

再次，这些问题在崩溃之前并不存在，参数是相同的，所以我很难理解文件系统的变化是罪魁祸首。

  1. 我了解到康维{www.j3e.de/linux/convmv/man/}。听起来很有希望，但显然没用，因为 8.3 和 LFN 似乎都是 UTF8 文件名。我还没有找到任何地方为这两种名称格式提供明确的编码。

  2. 我认为我应该考虑山选项，但是哪个？

我使用的挂载命令是

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

失败。

  1. 大多数 8.3 文件的父应用程序是 Gnome Evolution 电子邮件客户端。但同样，这些是备份文件，而不是崩溃中丢失的实际数据文件。因此，我仍然不明白原始 LFN 是如何在没有我采取任何直接行动的情况下神秘地变成 8.3 的。所以它一定是山或者文件系统属性问题。

再次感谢，安迪

相关内容