LINUX.ORG.RU
решено ФорумTalks

часть 1. Большой файл. FAT32 (windows7). fsck

 , ,


2

4

История эта началась с рутинного действия. По моей просьбе пользователь Windows 7 загрузил на свой компьютер большие файлы (у меня не было стабильного интернета). Большие файлы представляли собой «нарезку» образов под лимиты ФС FAT32. Человек скопировал файлы на мою флешку.

Поскольку я знаю, как обычные люди пользуются флешками на компьютерах с «виндой», то флешку ждала fsck. Первые строки вывода команды вроде бы подтверждали мои ожидания…

There are differences between boot sector and its backup.

fsck слегка призадумалась и после некоторой паузы выдала (подобных строк было много; для иллюстрации я оставил одну строчку)

[manjaro manjaro]# fsck /dev/sdb1
fsck from util-linux 2.37.4
fsck.fat 4.2 (2021-01-31)
...
/path/file.img
  File size is 4294963200 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
...

Такого я ещё не видел.

Первая мысль: флешку выдернули не просто без выполнения команды «Извлечь», но даже дописать файлы на флешку не дали. Я соглашаюсь с предложенным fsck лечением. Получаю в итоге файлы нулевой длины.

Дальше я напрашиваюсь в гости к моему добровольному помощнику – файлы-то мне забрать необходимо. Выполняю весь процесс самостоятельно: копирую файлы, делаю hash файлов, безопасно извлекаю флешку.

Подключаю флешку к своему ноутбуку. Для fsck ничего не изменилось

...
/path/file.img
  File size is 4294963200 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
...

В этот раз я от «лечения» флешки отказываюсь. Монтирую флешку в ro. Файлы читаются полностью. Хеш «оригиналов» совпадает с хешами файлов на флешке.

Где баг?

  • FAT32
  • fsck
  • ?

@Gonzo вот так выглядит моё «очевидное-невероятное» :)

Сперва я думал создать вопрос в General.

После того как я убедился в целостности файлов эта история больше, чем на Talks «не тянет».

Итог: «баг» ожидаемо оказался в fsck.fat. Спасибо @i-rinat: «пришёл и расставил все точки, где надо» :). В AUR есть пакет с фиксом.



Последнее исправление: master_0K (всего исправлений: 1)

Я соглашаюсь с предложенным fsck лечением. Получаю в итоге файлы нулевой длины.

После этого файлы нулевой длины были удалены, так? А после удаления fsck не запускался?

greenman ★★★★★
()
Ответ на: комментарий от greenman

После этого файлы нулевой длины были удалены, так?

Скорее «да», чем «нет».

А после удаления fsck не запускался?

Скорее всего «нет».

master_0K
() автор топика
Ответ на: комментарий от skyman

Не думаю, что дело в флешке.

Есть другой случай: ещё более запутанный, там возможно дело в носителе данных. Но сегодня я не готов его излагать.

master_0K
() автор топика
Последнее исправление: master_0K (всего исправлений: 1)

Ого, забавно. Да, порой fat/ntfs выкидывают чудеса. Тоже много всякого было раньше. С другой стороны, частые форматирования флешек под линухом их тоже убивали со временем.

Где баг?
FAT32
fsck
?

Где угодно. Баги в железе тоже бывают :)

Gonzo ★★★★★
()

Где баг?

В fsck. Я вчера не смог скопировать 1 файл DVD-диска в GNU / Linux Mint простым Thunar'ом. ДУмал диск зацарапан. В то время как сеодня оффтоик 10 скопировала и даже не заикнулась. Может быть он пытался читать на максимальнойскорости, а оффтоик на минимальной, но это не отменяет сырости любых дистрябов GNU / Linux.

xwicked ★★☆
()
Ответ на: комментарий от Gonzo

«Железо» здесь самый последний подозреваемый.

«Уникальная игра сил природы». Я тогда извлекал флешку на ПК с «виндой» и обратно подключал. «Винда» ничего, не жаловалась.

Если бы я и в первый раз сам проделал эту операцию, возможно бы и не узнал об этой ситуации в принципе. Не думаю, что в GUI файловый менеджер что-то заподозрил.

Как-то ещё под Debian был забавный эпизод: файловый менеджер после какого-то обновления разучился извлекать носители. Отмонтирует, а на «Извлечь» говорить «Невозможно». В консоли eject справлялся без вопросов (lsblk «свидетель» :)

Дело не в том, что есть «косяки». Они есть всегда, иначе бы логи были «тощими». Иногда задевает пользователя. Вот тогда и начинается «разбор полётов с погружением».

master_0K
() автор топика
Ответ на: комментарий от xwicked

Это Вы ещё Windows плотно не пользовались :)

Я плотно пользовался ещё Windows XP, остальные иногда вижу «со стороны». Так вот сколько лет прошло, а несколько тогдашних «приколов самой прогрессивной и совершенной ОС современности» не забуду никогда.

Любая ОС это инструмент.

master_0K
() автор топика
Последнее исправление: master_0K (всего исправлений: 1)
Ответ на: комментарий от master_0K

Windows XP

В плане кастомизации они все уродственны. Я со времён XP не изменяю ничего, юзаю дефолт. Так что я знаю о чём говорю. Сейчас в моём минте кривой драйвер для Tp-Link Bluetooth-приёмника. Скорость уродственна. Очень много мелочей не работают, которые работали ещё с времён XP, NTFS без аппаратных проблем вообще невозможно ушатать. С Fat32 чуть хуже дела конечно.

xwicked ★★☆
()
Последнее исправление: xwicked (всего исправлений: 1)
Ответ на: комментарий от xwicked

Вторая часть требует технического наполнения. Проблема скорее, всего именно в «железе». Брак или я «запарол». Лентяй во мне сейчас слишком силён. (

master_0K
() автор топика
Ответ на: комментарий от xwicked

Я недавно «трогал» Bluetooth. Узнал с удивлением, что привычные инструменты «выбрасывают». В принципе прогресс не заметен. Как и раньше может работать (как сейчас у меня), может не работать («хотя ещё вчера…»).

NTFS без аппаратных проблем вообще невозможно ушатать.

всегда примерно так и было. «МС» мог бы изменить ситуацию с поддержкой своей ФС, но им-то зачем?!

С Fat32 чуть хуже дела конечно.

Всегда думал, что довольно хорошо с FAT32 в linux. Поэтому на флешках обычно она несмотря на свои ограничения. Даже в описанной мной ситуации сложно винить саму FAT32

master_0K
() автор топика

Где баг?

FAT32

Фат позволяет пользоваться и дальше ФС, когда в ней 100500 неверных данных. И после таких сбоев неплохо бы стереть всю флешку и заново отформатировать. В добавок попадались всякого рода устройства (например, осциллограф), которые по своему усмотрению используют эту ФС. После них читается, но лучше ничего не писать.

fsck

Не шибко любит FAT и NTFS, и не все костыли использует, что есть в проверяльщике от оффтопика.

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR

после таких сбоев неплохо бы стереть всю флешку и заново отформатировать

Спасибо!

не все костыли использует, что есть в проверяльщике от оффтопика

fsck оффтопика в своё время доставил хлопот.

master_0K
() автор топика
Ответ на: комментарий от greenman

А, точно. Сколько применял его тогда, ни разу хорошего финала не видел: файлы в клочья на фрагменты.

master_0K
() автор топика
Ответ на: комментарий от AlexVR

Не шибко любит FAT и NTFS, и не все костыли использует, что есть в проверяльщике от оффтопика.

По поводу NTFS не знаю, но FAT тривиальнее некуда. Чего там можно было не учесть я не представляю. Скорее всего это просто какой-то тупой баг с каким-нить переполнением int-а при подсчёте кластеров.

firkax ★★★★★
()
Ответ на: комментарий от xwicked

На вторую часть скидывайте донаты.

rupert ★★★★★
()
Ответ на: комментарий от xwicked

Я вчера не смог...

Прохладная история.

anc ★★★★★
()

Зачем натравливать какую-то левую утилиту на флешку, без знания всё ли хорошо с ней и её содержимым?

shalom_ ★★
()

Где баг?

В fsck.vfat. Исправили вот тут: https://github.com/dosfstools/dosfstools/commit/ae94d63c46092bf95683dd964e4c1dc5c393458e

Со времени исправления ещё не было новых релизов dosfstools, так что они всё ещё только в master-ветке.

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Удивительно. Столько лет багу…

https://bugs.launchpad.net/ubuntu/+source/dosfstools/+bug/62831

и там упомянуто:

Onno Benschop (onno-itmaze) on 2007-01-04
Changed in dosfstools:
status:	Fix Committed → Fix Released

И у ТС немного другое число 4294963200

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 2)
Ответ на: комментарий от firkax

но FAT тривиальнее некуда. Чего там можно было не учесть я не представляю.

В файловой системе построенной на списках? Где таблица аллокации обычно кешируется? Не полные и битые цепочки, двойные ссылки из разных файлов на одни и те же сектора, потерянные блоки, не сохранённые поля в структурах фалов/каталогов. Изменение файлов в этой ФС предполагает изменение данных в разных местах. И это поверх флеш с её блочными операциями стирания.

Скорее всего это просто какой-то тупой баг с каким-нить переполнением int-а при подсчёте кластеров.

С виду в коде все нужные проверки приводятся к unsigned long long. Но вот сам алгоритм проверки – это портянка if-ов в цикле с кучей постоянно меняющихся и переиспользуемых переменных.

AlexVR ★★★★★
()
Ответ на: комментарий от shalom_

Левая это fsck?

без знания всё ли хорошо с ней и её содержимым

затем fsck и запускалась: убедиться, что всё хорошо. Или сбросить «грязный бит», если будет на него жаловаться. То. что в итоге получилось не было ожидаемым развитием событий.

master_0K
() автор топика
Ответ на: комментарий от firkax

Скорее всего это просто какой-то тупой баг с каким-нить переполнением int-а при подсчёте кластеров.

Блин, точно, только переполнение unsigned long и unsigned в исходниках используемых при сборке пакетов. Что-то глянул master ветку до этого. Прикольно. Догадайся что cluster chain lenght - это число кластеров (включая маркер конца) умноженное на размер кластера. Как раз до нуля переполняется.

З.Ы.: Но портянку так не понял до конца.

AlexVR ★★★★★
()
Ответ на: комментарий от i-rinat

Видимо, запатчили у себя, а апстрим уведомить о баге забыли. Странно.

Либо ещё раз баг на том же словили. Исходники debian 11 и ubuntu 22.04 с переполнением.

AlexVR ★★★★★
()
Ответ на: комментарий от i-rinat

Видимо, запатчили у себя, а апстрим уведомить о баге забыли. Странно.

https://bugs.launchpad.net/ubuntu/+source/dosfstools/2.11-2.1ubuntu2 – было с патчем

https://launchpad.net/ubuntu/+source/dosfstools/3.0.26-1 – было с uint64_t

https://launchpad.net/ubuntu/+source/dosfstools/4.1-1 – с uint64_t

https://launchpad.net/ubuntu/+source/dosfstools/4.2-1build3 – вернулись к unsinged long

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR

В AUR есть пакет патчем

...
if (!(file->dir_ent.attr & ATTR_DIR) && le32toh(file->dir_ent.size) <=
            (unsigned long long)clusters * fs->cluster_size) {
...

fsck.fat из AUR-пакета претензий к таким большим файлам не имеет.

master_0K
() автор топика
Ответ на: комментарий от master_0K

Замечательно. Но вот до 4.1 включительно было

    if (!(file->dir_ent.attr & ATTR_DIR) && le32toh(file->dir_ent.size) >
	(uint64_t)clusters * fs->cluster_size) {
	printf
	    ("%s\n  File size is %u bytes, cluster chain length is %llu bytes."
	     "\n  Truncating file to %llu bytes.\n", path_name(file),
	     le32toh(file->dir_ent.size),
	     (unsigned long long)clusters * fs->cluster_size,
	     (unsigned long long)clusters * fs->cluster_size);

Замечание: Этот блок чуть ниже.

Но у кого-то руки чесались. И исправили на

    if (!(file->dir_ent.attr & ATTR_DIR) && le32toh(file->dir_ent.size) >
	clusters * fs->cluster_size) {
	printf
	    ("%s\n  File size is %u bytes, cluster chain length is %u bytes."
	     "\n  Truncating file to %u bytes.\n", path_name(file),
	     le32toh(file->dir_ent.size),
	     (unsigned)clusters * fs->cluster_size,
	     (unsigned)clusters * fs->cluster_size);

Тем самым вернув старый баг.

Гениально просто.

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR

В Manjaro пакет dosfstools имеет версию 4.2-3. Версия 4.2 релизнулась 31 января 2021 года. В гите именно этот баг исправили год назад. «Всё закономерно».

master_0K
() автор топика
Последнее исправление: master_0K (всего исправлений: 2)
Ответ на: комментарий от firkax

Есть:

Remove useless casting to uint64_t or long long in check_file()

Value of clusters * fs->cluster_size is file size and it always fits into 32bit value. So use just unsigned int type for it.

Оптимизации. Без тестов. Что могло пойти не так?

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Этот код ещё и ревью наверное прошёл?

luke ★★★★★
()
Ответ на: комментарий от shalom_

Что «родную» лучше не использовать я ещё помню. И потом меня же предупреждали, что файл станет «нулевой длины». Проигнорировал? «Ну, да».

В таких случаях нельзя спешить, сначала

  • диагностика
  • бекап
  • возможно другие действия

Соль в том, что я принял неверное решение в той ситуации. Да обошлось, повезло.

master_0K
() автор топика
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)