LINUX.ORG.RU

tar входит в loop при архивации данных.

 ,


1

1

Доброго времени суток.

Столкнулся со странной ситуацией, во время которой при архивации tar'ом (из комплекта busybox) содержимого накопителя оный входит в loop и начинает наворачивать круги дублируя в архиве одну и ту же папку архивируя её повторно и заходя в неё же снова (как бы на уровень ниже) через доп. слэш «/».

«Полноценный» tar делал тоже самое, только вместо слэша там был некий символ «\016» (так текстом и написано в выхлопе tar'a было). В итоге папка весом в 5 мегабайт за 5 минут накрутила кругов на 1.5ГБ. 7za из комплекта p7zip тоже залипает при архивации, причём уже на этапе скана накопителя, напаррываясь на данную директорию при включении рекурсии (и всё так же спускается «вниз» по импровизированному дереву псевдо-директорий).

С накопителем полный порядок (e2fsck проблем не выявляет), левых юникодных символов через

ls -lanh ./

или

ls -lanh|od -c ./

я не вижу.

Что это за чертовщина ?

Пока единственным решением проблемы стало исключение «сбойной» директории из архивации.



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

Советую проверить, возможно ли из «проблемной» директории выйти «наверх» по символическим ссылкам или через директории, в которые что-то примонтировано через «mount -o bind»?

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

Ни биндингов, ни симлинков там нет. В том то и дело.

Но сейчас я заметил такой нюанс. При листинге директории через ls выше уровнем проблемной вместо

.
..

было


..

В терминале это хрен заметишь, особенно если не присматриваться, особенно когда выхлоп цветной.

Глянул выхлоп через «od -c» и вот он «левак» в виде символа «\016» (вместо символа перехода в текущую директорию), что вызывал петлю. Теперь другой вопрос - как это устранить (без удалений/перемещений данных в директориях ниже) и как это могло произойти ?

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

Точка это \056 а у тебя \016 вместо неё, выглядит как будто бит \040 перевернулся. Слышал что такое бывает в оперативной памяти (могло быть при создании это директории), а она обычно без контрольных сумм на десктопах.

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

По-хорошему fsck должен такое замечать, но если не замечает - ищешь где оно на диске лежит, оттуда dd в файл это место, правишь байт, dd назад на диск. Можно наверно даже не размонтировать, но лучше всё-таки с этим.

Для поиска где оно на диске - можно поискать утилиты по дампу ext3 (там она?) или вручную с форматом разобраться, он не сильно сложный. Самое долгое это «найти сектор по иноде» (инода директории в которой этот дефект, точка там в первом секторе её должна быть).

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

Точка это \056 а у тебя \016 вместо неё, выглядит как будто бит \040 перевернулся. Слышал что такое бывает в оперативной памяти (могло быть при создании это директории), а она обычно без контрольных сумм на десктопах.

Значит просто не повезло. Ясно.

По-хорошему fsck должен такое замечать, но если не замечает - ищешь где оно на диске лежит, оттуда dd в файл это место, правишь байт, dd назад на диск. Можно наверно даже не размонтировать, но лучше всё-таки с этим.

У меня похожие мысли возникли. Только наверное буду ковырять раздел через hex-редактор, всяко проще чем через dd. Без full-бкапа через dd всё равно не обойтись, так что какая разница чем раздел патчить ...

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

Без full-бкапа через dd всё равно не обойтись

Конкретно в связи с этой проблемой нужность бекапа не увеличивается.

А dd я имел ввиду как простое средство посекторного доступа к разделу.

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

В общем, на другой машине fsck обнаружил и пофиксил ФС, на целевой же он в упор проблем не видел (возможно кривоватый/старый чекер попался).

Вот только до этого я успел знатно помаяться с хекс-редактором в попытках найти проблемный участок. Поначалу мне казалось, что я его нашёл и поправив 0E на 2E, понял, что это оказался не он т.к. проблема так и не ушла, из-за чего пришлось всё откатывать взад (благо ФС я смонтировал для проверки в RO).

В связи с этим возник вопрос, как найти конкретную папку на диске с ext2 в hex-редакторе и заменить байт. Или провернуть тоже самое через dd. Желательно пошагово. Дабы в будущем снова не попасть впросак с этим проклятым одним байтом >_<

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

как найти конкретную папку на диске с ext2 в hex-редакторе

Порядок действий:

  1. узнаём её (проблемной папки) inode number командой ls -i, находясь в родительской по отношению к ней
  2. смотрим таблицу inode раздела (тут подробности не скажу), скажу только что inode table - глобальная со сквозной нумерацией на весь раздел, и (кажется) раскидана равными кусками равномерно по всему объёму раздела (т.е. условно 10кб очередной кусок таблицы, затем 1мб место под содержимое файлов, потом опять таблица итд)
  3. в найденной записи к этому inode number будет список блоков, в которых хранится директория, запись «.» скорее всего в самом начале самого первого из них

Ещё есть утилита ext3grep которая часть этого может автоматизировать.

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

Спасибо за мануал. Если в дальнейшем напорюсь на подобное, воспользуюсь им ;)

Blacksmith
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.