anyfs-tools 0.83

Интересная вещь. Но любопытно было бы, как это принято в научных работах, коей до некоторой степени можно полагать компьютерную программу, увидеть обзор аналогичных работ. Например, какого ты мнения о convertfs http://www.opennet.ru/prog/info/2695.shtml , может что ещё есть интересного? Чем отличается твоя программа, её преимущества.

А вот интересно, эта утилита в какой-нибудь live дистрибутив для восстановление системы входит?

Фигасе. Супер. Автору респект.

Автору безусловно РЕСПЕКТ! Причём реально большущий РЕСПЕКТ! Вот только... Я как раз несколько месяцев назад потерял свою огромную папку с моими фото и видео на vfat разделе... Если-бы эта прога была тогда.

какой недоумок делал им сайт:
кодировка не указана в заголовке страницы, вагон ошибок с незакрытыми тегами... и это на простейшей страничке!
очень надеюсь, что качество кода у них лучше, чем качество разммтки страницы на сайте.

>This document was created by man2html (from man 1.5o1), using the manual pages.

Так что все вопросы авторам вышеуказанной софтины..

Учитывая ограничения софтины для чего это надо? В реальной жизни ничего так восстанавливать не надо, развешто порушенные архивы порнухи и то только картинки, где найти не фрагментированный mpeg. В общем очередная утилита для красноглазых извращенцев

Что есть такое "unix-way набор утилит"? В том смысле, что с ними придется поипаццо, собрать из сырцов, перекомпилить пару либ, пересобрать ядро?

>Что есть такое "unix-way набор утилит"? В том смысле, что с ними придется поипаццо,

это ты с вин-веем перепутало, дитя поколения пепси

Ребята правильно ля и понял, я помощью этой утилиты можно восстанавливать удаленные файлы на ext2fs/ext3fs?

чегой-то не осилил ман - эта штука использует FUSE или они изобрели очередной велосипед и создали свой модуль ядра??

>>помощью этой утилиты можно восстанавливать удаленные файлы на ext2fs/ext3fs?<<

Если верить автору софтины, то - да, цитирую: "не зависит от файловой системы"

А подскажите утилиту, которая фрагментированные jpeg'и восстанавливает. Очень нужно! Фотки были перемещены с флешки фотоаппарата, а винчестер оказался битый...флешку после этого не трогал. восстановил многие при помощи какх-то прог под винду (одна искала по файловой системе, а другая как раз как сабдж - по типу контента), но многие так и не восстановились - были такие например, у которых одна половина от одной, а другая от другой фотки. У некоторых сохранилась превью иконка, а сама фотка не открывается.

Если такой программы в природе нету, то когда автор планирует добавить эту функцию в свою программу и насколько это реально?

To anonymous_incognito ****

По приведенной ссылке лежит программа свосем другого толка - одно дело - переконвертирование файловой системы из одной в другую, другое дело - восстановление данных. Какие тут сравнения? ;)

А при чем здесь фрагментированность? ;) Просто часть секторов, где лежали фотки, уже оказались затерты другой инфой - вот и не восстановилось, а виндовые утилиты вроде как все умеют восстанавливать фрагментированные данные - это первое требование к таким прогам (даже древние Нортон Утилитес допотопной версии это делали "на ура").

Про фрагментированность я решил потому, что после аварии флешку вообще не трогал - по сути было так - удалили с нее фотки, а потом сразу попытались восстановить (идеальный случай для такой программы насколько я понимаю). Были например еще такие фишки - одна половина фотки в одном файле, а другая в другом. Или одна фотка составлена из нескольких своих же кусков, только смещенных и в какой-то бледной цветовой гамме. Ничем другим кроме фрагментированности я такие вещи объяснить не могу.

Попробую ответить сразу всем.

Насчёт сравнения с convertfs:
если я не ошибаюсь, то convertfs нужно около 50% свободного пространства на диске, что хуже.
convertfs'у нужен драйвер исходной файловой системы с возможностью записи, да плюс ещё и с поддержкой sparse-блоков, т.е. даже из FAT она уже не сможет конвертнуть. anyfs-tools нужен лишь драйвер для чтения с поддержкой системного вызова FIBMAP.
Однако, вот с конечной ФС у anyfs-tools обстоит несколько хуже: у convertfs эта любая ФС с драйвером для записи, а у anyfs-tools -- пока только ext2fs/ext3fs.

"в какой-нибудь live дистрибутив для восстановление системы" эта утилита разумеется пока не входит -- она же только вышла в свет (это её первый релиз).

За респект'ы спасибо.

Насчёт ошибок в html-коде: благодаря тому, что весь сайт генерится из man'ов одним bash-скриптом, подправить всё разом будет не сложно. Займусь вечером.

> В реальной жизни ничего так восстанавливать не надо
Да, у вас просто сказочная жизнь, anonymous!

> Что есть такое "unix-way набор утилит"?
Если вы не знакомы с этим термином, то: Это есть набор утилит, каждая утилита в котором занимается _своим_ маленьким делом, но днлает его хорошо.

> Ребята правильно ля и понял, я помощью этой утилиты можно восстанавливать удаленные файлы на ext2fs/ext3fs?
Да, правильно. Восстановление напрямую от файловой системы не зависит. Там несколько другие ограничения.

> эта штука использует FUSE или они изобрели очередной велосипед и создали свой модуль ядра??
Странные у вас представления о велосипедах. Да, драйвер файловой системы там не user-space.

> А подскажите утилиту, которая фрагментированные jpeg'и восстанавливает.
Пока можете попробовать anyfs-tools'ом восстановление в два прохода -- в первый найдутся все не фрагментированные файлы, а во-второй (используя опцию anysurrect -i) т.к. поиск будет происходить только по незанятым блокам, то может быть найдётся некоторые и фрагментированные файлы.

> когда автор планирует добавить эту функцию в свою программу и насколько это реально?
Это вполне реально для некоторых типов файлов, входит ли в их число JPEG сказать сложно, но на первый взгляд -- скорее всё же да.
А вот "когда" ещё более сложный вопрос -- может через пару недель.

> одно дело - переконвертирование файловой системы из одной в другую, другое дело - восстановление данных. Какие тут сравнения? ;)
Сравнения ещё те -- anyfs-tools занимается и первым и вторым. Чтобы понять, надо внимательно посмотреть на порядок применения утилит для конвертирования и восстановления данных, и увидеть, что переконвертирование ФС -- это часть процесса восстановления данных.

>А вот "когда" ещё более сложный вопрос -- может через пару недель

Так быстро! Тогда буду ждать новостей о новой версии :)

Автору респект! Именно такой программы мне лично и не хватало. Хотелось бы знать, работает ли сия тулза под amd64 в 64-битном режиме.

<это ты с вин-веем перепутало, дитя поколения пепси>

В фортунки!

<Насчёт сравнения с convertfs: если я не ошибаюсь, то convertfs нужно около 50% свободного пространства на диске, что хуже. convertfs'у нужен драйвер исходной файловой системы с возможностью записи, да плюс ещё и с поддержкой sparse-блоков, т.е. даже из FAT она уже не сможет конвертнуть. anyfs-tools нужен лишь драйвер для чтения с поддержкой системного вызова FIBMAP. >

Насколько я помню документацию по convertfs, там совсем не нужно около 50% свободного пространства на диске, да и опыт мой говорит о другом.

Делал пару раз достаточно давно, но сколько помню свободного места нужно немного, всего ничего. convertfs требует изначально немного места, а потом как бы динамически двигает границу разделов на конвертируемом диске.

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

> Хотелось бы знать, работает ли сия тулза под amd64 в 64-битном режиме.

Должна, а там нужно смотреть на практике.

>А подскажите утилиту, которая фрагментированные jpeg'и восстанавливает

можешь попробовать fatback http://fatback.sourceforge.net/

Автору респект! Утилит такого рода не хватает под Linux-ом.

Под оффтопик подобное давно было. Хотябы тот же самый ontrack easy recovery.

reblock.c:(.text+0x2c5): undefined reference to `find_next_zero_bit'

если подсунуть ему bitops.o из /usr/src/linux/arch/i386/lib, то оно собирается. но... any.ko приходится собирать отдельно "cd anyfs ; make"

"make install" начинает _полностью_ пересобирать ядро и устанавливать модули, причем, any.ko среди них так и не появляется. ладно, кладем any.ko в extra, пускаем depmod и пробуем загрузить: FATAL: Error inserting any (/lib/modules/2.6.14-gentoo-r3/extra/any.ko): Unknown symbol in module, or unknown parameter (see dmesg)

dmesg говорит: any: Unknown symbol __udivdi3

> MPEG3

Охренеть, может mpeg1 layer 3?

> reblock.c:(.text+0x2c5): undefined reference to `find_next_zero_bit'

Странно, а 'make arch' нормально проходит?

> если подсунуть ему bitops.o из /usr/src/linux/arch/i386/lib, то оно собирается. но...
Хм.. по идее он автоматически должен /usr/src/linux/arch/i386/lib/lib.a подсовывать.
У вас `uname -i` что выдаёт??? Если это не "i386" то проблема в этом.. как же в этом случае более корректно узнать архитектуру?...

> any.ko приходится собирать отдельно "cd anyfs ; make"
Это ещё более странно. `make fs` проходит?

> "make install" начинает _полностью_ пересобирать ядро и устанавливать модули, причем, any.ko среди них так и не появляется.
> ладно, кладем any.ko в extra, пускаем depmod и пробуем загрузить:
> FATAL: Error inserting any (/lib/modules/2.6.14-gentoo-r3/extra/any.ko): Unknown symbol in module, or unknown parameter (see dmesg)
>
> dmesg говорит: any: Unknown symbol __udivdi3

Ядро 2.6.14-gentoo-r3... интересно, это всё особенности ядра 2.6.14 или gentoo-сборки..
Я мягко, говоря тоже не знаю символа udivdi3 -- ни единого его упоминания в исходных кодах моего модуля нет. И после сборки у меня `nm any.ko | grep udivdi3` тоже выдаёт пустоту.
Кажется мне не мешало бы ядро обновить..

Вообще, вы бы на почту мне писали..

> Охренеть, может mpeg1 layer 3?
Именно так "mpeg1 layer 3" более известный как "MP3" или "MPEG3" -- сами посмотрите, google помучайте.

Кстати "__udivdi3" может быть как раз из bitops.o?
Попробуйте всё же весь linux/arch/i386/lib/lib.a подставить.
А про вывод `uname -i` всё же напишите.

С uname -m не перепутал? Кстати, в Debian'е uname -m выдаёт i686 и сильно подозреваю, что i386 мало на каких дистрах будет.

P.S. Твой набор утилит я не пробовал ещё собирать :)

> По приведенной ссылке лежит программа свосем другого толка - одно дело - переконвертирование файловой системы из одной в другую, другое дело - восстановление данных. Какие тут сравнения? ;)

Автор и про конвертацию говорит, так что смысл сравнивать есть.

> С uname -m не перепутал? Кстати, в Debian'е uname -m выдаёт i686 и сильно подозреваю, что i386 мало на каких дистрах будет.

Вот именно! У меня тож `uname -m` i686, а вот `uname -i` как раз i386.

это снова анонимус с проблемами при сборке

# uname -i GenuineIntel

# uname -m i686

$ make arch For building on not i386, x86_64 platforms, `make arch` not needed

вечером еще раз попробую с lib.a собрать

> Вот именно! У меня тож `uname -m` i686, а вот `uname -i` как раз
i386.

Всё страньше и страньше, как говаривала Алиса в Зазеркалье.

=================

$uname -i
Попробуйте `uname --help' для получения более подробного описания.

$uname --help
Использование: uname [КЛЮЧ]...
Печатает определенные сведения о системе. Если КЛЮЧ не задан,
подразумевается -s.

-a, --all напечатать всю информацию, в следующем порядке:
-s, --kernel-name напечатать имя ядра
-n, --nodename напечатать имя машины в сети
-r, --release напечатать номер выпуска операционной системы
-v, --kernel-version print the kernel version
-m, --machine print the machine hardware name
-o, --operating-system print the operating system
--help показать эту справку и выйти
--version показать информацию о версии и выйти


Об ошибках сообщайте по адресу <bug-coreutils@gnu.org>.

$uname -a
Linux michael 2.6.8-2-k7 #1 Tue Aug 16 14:00:15 UTC 2005 i686 GNU/Linux


==================

Где uname -i ?

Спасибо за информацию. Значит `uname -i` мягко говоря непортабелен. Будем использовать как в Makefile'е ядра:
$ uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/ -e s/s390x/s390/ -e s/parisc64/parisc/

Новый релиз в связи с этим я уже положил.

Пытаюсь сейчас собрать твою программу. Скажи, версия ext2fs >=1.38 это у тебя принципиальное требование? Просто я сейчас, по возможности, Debian 3.1 использую и там ext2fs версии 1.37.

> Пытаюсь сейчас собрать твою программу. Скажи, версия ext2fs >=1.38 это у тебя принципиальное требование?
Ну достаточно -- у одного товарища с 1.2x какой-то кажется не собирался.

> Просто я сейчас, по возможности, Debian 3.1 использую и там ext2fs версии 1.37.
С 1.37 вроде не пробовали собирать -- попробуйте, если builde2fs не будет собираться значит принципиальное.

> версия ext2fs

На всякий случай замечу, что всё же не ext2fs, а e2fsprogs -- совершенно разные вещи:
e2fsprogs на самом деле практически не имеет никакого отношения к драйверу ext2fs в ядре.

Изменил в configure EX2FS_REQUIRED с 1.38 на 1.37 возымело ли эффект 
пока не известно, потому что не проходит make arch

# make arch
make  -C /lib/modules/2.6.8-2-k7/build arch/i386/lib
make[1]: Entering directory `/usr/src/kernel-headers-2.6.8-2-k7'
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/split-include
  HOSTCC  scripts/basic/docproc
  LD      arch/i386/lib/built-in.o
make[2]: *** Нет правила для сборки цели `arch/i386/lib/bitops.o', требуемой для `arch/i386/lib/lib.a'.  Останов.
make[1]: *** [arch/i386/lib] Ошибка 2
make[1]: Leaving directory `/usr/src/kernel-headers-2.6.8-2-k7'
make: *** [arch] Ошибка 2

Непонял откуда должно взяться built-in.o?

И вообще я не понял, ты что _всё_ ядро пересобираешь для этих утилит? Хотелось бы варианта попроще, неужели отдельным модулем не обойтись?

> Непонял откуда должно взяться built-in.o?

То есть, как его подцепить? Я так понял, что уже не у меня одного проблема возникает.

> И вообще я не понял, ты что _всё_ ядро пересобираешь для этих утилит?

Всего лишь `make arch/i386/lib` -- какое же это "всё ядро"?

> make[2]: *** Нет правила для сборки цели `arch/i386/lib/bitops.o', требуемой для `arch/i386/lib/lib.a'. Останов.

А `make arch/i386/lib/bitops.o` так же закончится?
Вообще-то весьма странно..

$ make arch
make -C /lib/modules/2.6.11.1/build arch/i386/lib
make[1]: Entering directory `/usr/src/linux-2.6.11'
CHK include/linux/version.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/split-include
HOSTCC scripts/basic/docproc
HOSTCC scripts/genksyms/genksyms.o
HOSTCC scripts/genksyms/lex.o
HOSTCC scripts/genksyms/parse.o
HOSTLD scripts/genksyms/genksyms
CC scripts/mod/empty.o
HOSTCC scripts/mod/mk_elfconfig
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/modpost.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
HOSTCC scripts/kallsyms
HOSTCC scripts/pnmtologo
HOSTCC scripts/conmakehash
HOSTCC scripts/bin2c
CC arch/i386/kernel/asm-offsets.s
CHK include/asm-i386/asm_offsets.h
UPD include/asm-i386/asm_offsets.h
LD arch/i386/lib/built-in.o
CC arch/i386/lib/bitops.o
AS arch/i386/lib/checksum.o
CC arch/i386/lib/dec_and_lock.o
CC arch/i386/lib/delay.o
AS arch/i386/lib/getuser.o
CC arch/i386/lib/memcpy.o
CC arch/i386/lib/strstr.o
CC arch/i386/lib/usercopy.o
AR arch/i386/lib/lib.a
make[1]: Leaving directory `/usr/src/linux-2.6.11'

Т.е. built-in.o весьма успешно берётся..
Может в самом деле всё ядро проще собрать? Только вот будет ли там arch/i386/lib/lib.a в процессе собрано?

Вообще мне lib.a этот понадобился лишь потому, что почему-то функция find_next_zero_bit (inline-функция!) для i386 оказалась вынесена в bitops.c, а в bitops.h она не определена (ну заголовок там разумеется есть).

Вообще-то я сначала пытался использовать заголовки /usr/include/asm/bitops.h, но это тоже оказалось не портабельно.
Сейчас используются заголовки непосредственно из исходных кодов ядра, но вот и тут какие-то казусы..
Одним словом ужас!
Как же сделать портабельно... Нужны-то всего лишь элементарные функции по работе с битовыми картами.

> А `make arch/i386/lib/bitops.o` так же закончится? Вообще-то весьма странно..

Разумеется также.

> Может в самом деле всё ядро проще собрать?

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

> Вообще мне lib.a этот понадобился лишь потому, что почему-то функция find_next_zero_bit (inline-функция!) для i386 оказалась вынесена в bitops.c, а в bitops.h она не определена (ну заголовок там разумеется есть).

И стоило из-за неё столько городить? Включи её методом Copy/Paste в свою программу это же пара команд на ассемблере x86.

> Как же сделать портабельно... Нужны-то всего лишь элементарные функции по работе с битовыми картами.

Можно же вообще обойтись системнонезависимым, с точностью до Big или Little Endian, кодом, если производительность сильно не упадёт.

Во всяком случае, что-то я сомневаюсь, в правильности использования функций из модуля ядра для работы с битами, посмотри хотя бы исходники упаковщиков (gz, zip и др.)

>> Может в самом деле всё ядро проще собрать?
>
> Для себя сколько угодно, но если ты делаешь для массового применения, то это
> недопустимо без действительной необходимости.
Я не говорю про общий случай -- я про ваш конкретно :-)

> И стоило из-за неё столько городить? Включи её методом Copy/Paste в свою программу это же пара команд на ассемблере x86.

Ну, как же! Мы претендуем на архитектуро-независимость --не копировать же мне всю директорию arch.

> Можно же вообще обойтись системнонезависимым, с точностью до Big или Little Endian, кодом, если производительность сильно не упадёт.

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

> Во всяком случае, что-то я сомневаюсь, в правильности использования функций из модуля ядра для работы с битами, посмотри хотя бы исходники упаковщиков (gz, zip и др.)
gzip, bzip2 -- не показательны, гораздо более показателен тот же e2fsprogs -- да они в progs'ах использовали свою реализацию -- правда там find_next_bit_set, т.е. просто использовать эти функции из библиотеки e2fsprogs я не могу -- мне то нули нужно искать. Как бы то ни было я могу сказать почему они просто _не_могли_ поступить иначе, почему они не могли использовать функции ядра:
они претендуют на осе-независимость (т.е. mke2fs во FreeBSD тоже должен работать)! Но мне то оно не надо -- у меня уже там столько завязано на Linux, на ядро, что возможность скомпилировать пару утилит на той же FreeBSD, ничего не изменят -- в целом пакет будет не работоспособен.

> Ну, как же! Мы претендуем на архитектуро-независимость --не копировать же мне всю директорию arch.

Решать тебе. Я бы скопировал %-) не всю, конечно, а только нужные функции, не зависящие от других, исключительно машинные реализации.

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

> у меня уже там столько завязано на Linux, на ядро,

Опять же решать тебе, но я бы постарался чётко разделить код на системнонезависимую часть и зависящую от ядра. Причём такие вещи как поиск нулевого бита, по-моему должны быть всё-таки не завязаны на ядро. В идеале даже сделать свой промежуточный API для системнозависимых вещей, что позволит легко портировать твою программу на разные системы. А пока что у тебя возникли проблемы переносимости даже внутри разных вариантов Linux.

Кстати, этот buil-in.o вообще занимает 8 байт:

$cat cat built-in.o

!<arch>

> В идеале даже сделать свой промежуточный API для системнозависимых вещей, что позволит легко портировать твою программу на разные системы.
По-моему, вещь на самом деле не портируемая совсем -- в конце концов даже в e2fsprogs filefrag -- "only for Linux" -- а это считай основа всего пакета, поэтому на портируемость между осями мы сразу мягко говоря ложим болт.

> А пока что у тебя возникли проблемы переносимости даже внутри разных вариантов Linux.
Горькая правда. Главное совершенно не ясно куда у вас делось "правило для сбоки `arch/i386/lib/bitops.o'"

> Кстати, этот built-in.o вообще занимает 8 байт:
Любопытное замечание :-)
Однако у меня ровно также, а значит built-in.o у вас правильно собирается.
Скажите, а у вас в /usr/src/linux/MakeFile есть такое правило:

%.o: %.c scripts FORCE
$(Q)$(MAKE) $(build)=$(@D) $@

??
Да и лучше б вы всё же на почту писали.

> make[1]: Entering directory `/usr/src/kernel-headers-2.6.8-2-k7'
Слушайте!!! А что это за "kernel-headers-2.6.8-2-k7"???
Это же не сырцы, не "linux-2.6.8-2-k7"! Поэтому, наверное, не собирается...