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

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

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

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

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

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

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

Заменить флешку пробовали?

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

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

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

Где баг?
FAT32
fsck
?

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

Где баг?

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

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

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

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

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

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

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

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

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

Windows XP

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

часть 1.

И когда ждать вторую часть?

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

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

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

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

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

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

Где баг?

FAT32

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

fsck

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

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

Спасибо!

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

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

chkdsk?

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

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

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

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

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

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

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

Где баг?

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

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

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

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

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

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

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

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

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

Левая это fsck?

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

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

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

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

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

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

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

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

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

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

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

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

Замечательно. Но вот до 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);

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

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

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

В коммите есть обоснование?

Есть:

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.

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

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

Да, левая, а что, она родная для FAT32? Хорошо что там не хранилась какая-то уникальная информация

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

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

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

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