Удалить файл без inode на ext4

Fsck не почистит? У меня такое было когда диск посыпался.

Делал fsck -AR -t ext4 -y, не помогло.

Как видно, inode отсутствует.

Хорош чудить с воображаемым глобусом.

Я вижу, ты умный парень. Знаешь, что делать, или поговорить зашёл?

Знаешь, что делать, или поговорить зашёл?

Пока думаю, как воспроизвести. Не подскажешь?

e2fsck -Dfv ...

Да кто же знает. Свет Луны отразился от болотного газа...

Да кто же знает.

Что даст?:

$ cd ~/Раз/Два
$ find .

Выглядит странно. Оставлю напоследок — придётся ребутиться в рекавери.

./Рабинович

Там ещё папки есть?

В той же папке — есть и папки и файлы. Они отображаются нормально. С ними можно работать. Только Рабиновичу не повезло.

Только Рабиновичу не повезло.

Так не пробовал: коментарий: Удаление файлов с неправильной кодировкой в имени : loozz (23.12.17 12:51:16). Потому что я «слегка» не понимаю существования «файла» без инода.

Как я это попробую, если инода нету?

Вот тут, https://unix.stackexchange.com/questions/287947/delete-file-with-missing-inod... человек вструтился с той же проблемой, но сдался.

Как такое может быть, не знаю. Вроде в ext4 есть несколько таблиц на случай повреждения. Вряд ли они все одновременно побились в одном месте.

Файловая система похоже крякнула. Тут если чинить, то только инструментами починки ext4 (но только чини на копии, а не оригинале). Ничего ты не сотрешь штатными методами, не пытайся.

придётся ребутиться в рекавери.

Почему не?:

$ sudo mount -o remount,ro /

Ничего не сработало, ни e2fsck, ни debugfs (не находит папку с Рабиновичем, полагаю, из-за русскоязычных имён). Хоть вспоминай юность и дебажь файлуху хекс-едитором. Сложность в том, что это /home и там много гигов... Хер с ним. Пусть будет так. Надеюсь, этот баг не размножается. В любом случае, всё важное забекаплено. Спасибо всем, кто откликнулся.

Ничего не сработало

Плохая ситуация, очень плохая. Возникают вопросы: Это связанно именно с ext4, или со всем семейством ext? Причины приводящие к подобным повреждениям фс? На что тратятся служебные блоки семейства ext?

Вродь в новых ядрах был баг ext4, приводящий к потере данных.
Какая версия ядра ?

Была убунта 16.04, там всё было ОК, и корневой и домашний разделы были на ext4. Поставил 18.04 - корневой раздел отформатировал, а домашний оставил. сразу заметил, что дропбокс без остановки крутит свои стрелки, обновляет что-то. Оказалось, это Рабинович окуклился.

При установке было ядро 4.18.0-17. Сейчас *-18.

А куда бежать? XFS тоже ругают. Вроде, теряет файлы после сбоев.

А куда бежать?

Если это именно ext4, то на ext3. А если всё семейство ext, то считай фаталити, у других фс тоже проблемы есть. Хоть мой reiserfs меня ни разу не подводил - это воля случая.

А куда бежать?

Если LVM есть ещё вариант держать небольшой home для личной помойки (20-30G), а всё остальное держать отдельным разделом.

Баг был на 4.19.

Странно что никто еще не посоветовал начать со смарта диска. А то задача сильно похожа на XY.

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

rm -rf

Внутри проблемной директории также есть несколько файлов.

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

в том или ином случае фс поломат.

Пробовал, конечно. Как поменять атрибуты?

chown

chmod

попробуй удалить от root.

В этой директории были файлы, пока она ещё была директорией. Иноды этих файлов мне неизвестны, но они, возможно, в порядке.

Тут такое дело. Рабинович нашёлся:

$ ext4magic /dev/sda1 -L -f 'user/Раз/Два'
...
DIR     770      user/Раз/Два/Рабинович
...

Примечательно, что команда

$ ext4magic /dev/sda1 -D -f 'user/Раз/Два' -d /root/save

ext4magic обнаружила эту директорию, её инод

Так по иноду через find удали.

Та же фигня: «Структуру необходимо почистить»

Та же фигня: «Структуру необходимо почистить»

Уточняю: Вот так не получилось?:

$ cd user/Раз/Два
$ find . -inum [inode-number] -exec rm -i {} \;

Где inode-number берётся из выхлопа ext4magic (сам выхлоп не видел, только ман читал).

Именно.

Этот inode занят? find -inum 770 (команду не проверял!)

Именно.

И так?:

$ cd user/Раз/Два
$ find . -inum [inode-number] -delete

find -inum 770

А я думал 770 - это права.

У папки /home/user/Раз/Два inode=659 и чо?

И так.

Рабинович Никогда не связывайся с евреями. Они в любой ситуации намутят.

Извини, не заметил вопрос. То же самое: «Структуру необходимо почистить».

И так.

В xfs это лечится xfs_repair -L

$man xfs_repair
...
-L     Force  Log  Zeroing.
...

Но в e2fsck я такого не нашёл. (

А я подумал, что это inode, который когда-то занимал Рабинович. Как на самом деле — хз

Да мне особо обижаться не на что — сам напросился :)

Я не спец по внутреннему устройству ext4. Но, «логика» примерно такая: создается директория

• в некую структуру (вероятно, родительский каталог) ФС записывается её имя
• имя связывается с inode
• inode указывает на содержимое этой директории
• возможно ещё что-то делается, а главное все* эти операции заносятся в журнал

Теперь посмотрим на этого «Рабиновича». У него потерялся inode. Сам он есть (т.е. родительский каталог цел) и в нём содержатся файлы (вот это я не совсем понимаю; но, это «нормально» — я во внутреннем устройстве ext4 не разбираюсь). Вот я и подумал, а «где» сейчас этот inode.

По теме: эта «поломка», видимо, очень не типичная. Поэтому и не получается её устранить. Самый «простой» способ — перенести данные и пересоздать ФС. Другой вариант: разбираться в устройстве ext4 и пытаться откатить ситуацию до нормального состояния.

UPDATE
Никто не предложил такой способ

• копируешь содержимое ~/Раз/Два куда-то, главное Рабиновича не бекапь
• сносишь этот каталог Два (вот здесь может и не получиться)
• восстанавливаешь из бекапа

Снести как раз и не получается. Видимо функции rm, find и прочие основаны на одной либе, которая не может переварить эту ситуацию, а ext4magic — на другой. Точнее, ext4magic, похоже, сама реализует логику работы с ФС, потому что в её зависимостях есть только библиотека работы с блочными устройствами и другая, для расширенных атрибутов.

Видимо функции rm, find и прочие основаны на одной либе

в её зависимостях есть только библиотека работы с блочными устройствами и другая, для расширенных атрибутов.

Вообще-то у всех в зависимостях неявно присутствует ядро, и с дисковым форматом ФС взаимодействие обычно оно. Так что говорить в первом случае следует не о «либе».

функции rm, find и прочие основаны на одной либе

они работают с текущим состоянием ФС

ext4magic

использует журнал ФС для реконструкции (наверно, и другие какие-то методы тоже)

А какие-то операции с этим каталогом (копирование, перемещение, переименование, смена прав, ...) успехом завершались? Какое-то особое стечение внешних факторов создало «уникальный» объект ФС. В принципе это баг.

Одна из директорий каким-то образом получилась такой:

Каким образом?