Мой 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. Единица

    Western Digital (WD) "My Book" Essential 2 ТБ NAS

  2. Основная проблема связана с тысячами локальных папок электронной почты и сообщений для почтового клиента Linux Gnome Evolution. У меня есть отдельная более старая резервная копия на твердотельном накопителе USB WD FAT32, которая сохраняет LFN для папок, но сообщения там гораздо старше. Попытка скопировать более новые файлы резервной копии (8.3) просто игнорирует старые файлы LFN и сохраняет как 8.3, дублируя содержимое.

  3. После сбоя я не сохранял никаких файлов ни на SSD, ни на NAS, поэтому не могу представить, что их содержимое действительно было изменено, скорее подозреваю, что моя новая конфигурация неправильно их читает.

  4. Мы переформатировали корневой раздел (/) как btrfs и раздел данных XFS в соответствии с рекомендациями операционной системы (openSUSE Leap 42.1) в ходе восстановления. Раздел данных зашифрован LUKS. Корневой раздел и раздел данных изначально были Ext4. Надеюсь, LFN не должен зависеть от Ext4?

  5. Ограничения пути и имени файла составляют 4096/255 соответственно для основной системы и NAS:

{} 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?страница = содержание & ID = 3011981 & АСТР = поиск & viewlocale = en_US & searchid = 1452757427425}

говорит, что длина пути включена в ограничение NAME_MAX , что, безусловно, объясняет проблему. Но это не было проблемой до крушения, поэтому мне интересно, почему это сейчас?

Ото

{en.wikipedia.org/wiki/Comparison_of_file_systems} (да, я не знаю правильного технического справочника, но в любом случае полезен>:-)

повторяет getconf NAME_MAX ограничения выше, и говорит , что для Btrfs и файловых систем XLS нет предела PATH_MAX.

Опять же, эти проблемы не существовали до сбоя, параметры те же, поэтому у меня проблемы с пониманием того, что изменение файловой системы является виновником.

  1. Я узнал о convmv {www.j3e.de/linux/convmv/man/}. Звучит многообещающе, но, видимо, бесполезно, так как кажется, что 8.3 и LFN - это имена файлов UTF8. Я не нашел ни одного места, которое дает явную кодировку для этих двух форматов имен.

  2. Я вижу, что я должен рассмотреть варианты монтирования , но какие?

Команда монтирования, которую я использую,

mount -t cifs -o guest //192.168.5.1/"My Book "/mnt /NAS

Это работало нормально, прежде чем все это произошло. Как мы знаем, параметры для монтирования так же исчисляемы, как звезды ... :-(

Как я понимаю, это монтирует диск как диск NFS. Просмотр 8.3 имен файлов противоречит приведенной выше цитате kb.netapp.com , в которой говорится:

Короткие имена появляются на клиентах, которые поддерживают только формат 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.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 и монтирует NAS как chown andy:users, но файлы по-прежнему отображаются как 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

выходит из строя.

  1. Родительским приложением для большинства файлов 8.3 является почтовый клиент Gnome Evolution. Но опять же, это файлы резервных копий, а не фактические файлы данных, которые были потеряны в результате сбоя. Так что я продолжаю уклоняться от того, как оригинальные LFN загадочно стали 8.3 без каких-либо прямых действий с моей стороны. Так что это должна быть проблема свойств монтирования или файловой системы .

Еще раз спасибо, Энди

|источник

0