Есть файловые системы, которые хранят только уникальные файлы?

durka82

То есть если в нескольких папках лежат одинаковые файлы - то они должны храниться только как один файл.
Но если изменяется один из файлов - не факт, что меняются все (например, система должна спрашивать).
Есть такое?

vall

например, система должна спрашивать
как ты это себе представляешь?

durka82

Вариантов много:
1. Свойство файла, что делать по умолчанию
2. Аналогичная установка на уровне системы
3. Работа с такими отзеркаленными файлами как с единым целым (то есть например при запросе на открытие файла нужно указывать, открываешь ты его весь, или только конкретную копию)

Codcod

cvs

mira-bella

Файловые системы с хардлинками представляют все возможности для такой схемы работы, но их схема работы в современных файловых системах обычно не такая.

Andbar

пример - загружаемые на этот форум файлы...

durka82

А какой у него вариант поведения?

durka82

То есть если повторно закачивается что-то, ссылка будет дана на уже существующий файл?

Andbar

да.... Никогда не замечал, что иногда загрузка файла происходит долго? Я так понимаю, если встречаются одинаковые по размеру файлы, то он проверяет на совпадения.

vall

врядли всё так тупо - наверняка md5 в базе хранится для каждого файлика.

CapitanJack

есть спец системы хранения - CAS content adressed storage. и делает такое чудо EMC, называецца Centera
по сто тонн уев за терабайт

durka82

Меня пока интересуют только программные решения.

CapitanJack

на самом деле это и есть программное решение - на аппаратном уровне там просто одноюнитовые сервера.

у тебя задача то какая изначально?

durka82

Просто экономия места на диске + уменьшение энтропии.
Например, часто попадаются расчетные проекты, когда просто делают несколько копий проекта, варьируют в каждой параметры, а потом компилируют и считают. В результате может получиться, что в папках только процентов 30 файлов(по размеру) различаются - остальные одинаковые. Понятно, что это можно решать на уровне организации таких проектов, написанием скриптов и тп, но если есть готовое решение - почему бы его не использовать?..
Еще пример - сохраняешь несколько страниц с одного (и даже необязательно с одного) сайта - получаешь кучу общих мелких картинок, css и тп.
В дистрибах тоже бывают файлы, одинаковые для кучи дистрибов (наверное которые получены с помощью одной проги-инсталлятора).
Даже задачу множественной категоризации можно решать на файловой системе при условии, что такая фишка работает

durka82

Так как насчет подробностей про cvs?

Andbar

ну.. мб. и так, но по субъективной оценке,при совпадении страница выдаётся очень долго. Скорее всего сначала идет сравнение по размеру и мд5-сумме, а потом уже - побайтно.

durka82

ап

gopnik1994

да нет, именно так тупо
меня ломало писать что-то хорошее, потому написал быстро
просто не расчитывалось, что там будет лежать 100,000 файлов....

Ivan8209

Использовать полноценную БД вместо ФС?
---
...Я работаю антинаучным аферистом...

Ivan8209

В топку.
Подробности нужны?
---
...Я работаю антинаучным аферистом...

durka82

Это вариант, но тогда придется писать весь софт, аналогичный существующему для ФС - тот же ТС, например
Или не все так печально?
Опять же та же нтфс - тоже БД - мб можно ее малой кровью доработать?

durka82

Нужны.

vall

судя по тому как оно сейчас работает - самое время поправить
может конечно это сетка, но аплоадится порой очень долго.

Ivan8209

Что такое "ТС"?
Ты под винду хочешь?
Райзеровцы делают что-то похожее на то, что тебе надо.
По крайней мере, несколько лет назад заявляли об этом.
Вернее, оно могло бы быть тебе полезным.
---
...Я работаю...

gopnik1994

это теперь не ко мне

Ivan8209

Проблемы начнутся сразу, CVS --- это версионная система, всё-таки.
Появится два имени у файла --- расхождение, надо отлавливать check-in,
ссылками всё равно не воспользуешься, поэтому всё равно будут храниться одинаковые файлы.
Либо отлавливать и check-out.
То есть, всё равно писать хранилище, только поверх CVS.
---
...Я работаю...

Ivan8209

> попадаются расчетные проекты
Народ обычно работает по схеме make -> текстовый процессор -> расчёт -> архиватор.
---
...Я работаю...

durka82

Что такое "ТС"?
Тотал командир
Ты под винду хочешь?

Не обязательно.
Я давно посматриваю в сторону никсов (точнее в сторону от вина а если еще такой повод будет - вообще круто
Райзеровцы

Это кто такие?

durka82

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

Почему?
Он всегда после чекаута создает новую копию файла, независимо от изменений?

Sharp

Если я тебя правильно понял, тебе нужно что-то типа unionfs.
http://www.freebsd.org/cgi/man.cgi?query=mount_unionfs&a...
Сам никогда не пользовал, но по отзывам глючит достаточно часто. Так что можешь попробовать, составишь свое личное мнение.

durka82

Народ обычно работает по схеме make -> текстовый процессор -> расчёт -> архиватор.

Ну да, а архивы потом выбрасывать можно, так как они как правило никогда использоваться не будут (по разным причинам)

durka82

Спасибо, попробую
А глючит критично или по-мелочи?

Sharp

Народ ругается, но продолжает пользоваться.
Значит пользоваться можно.

Ivan8209

Если использовать check in/out схему, то придётся отказаться от старых файловых менеджеров.
Под виндой всё будет значительно сложнее.
Тебе же требуется загнать то, что ты хочешь, поближе к системе (желательно, вовсе в систему).
ReiserFS --- это http://www.namesys.com/
unionfs --- это тоже похоже на то, что ты хочешь.
---
...Я работаю...

sergey_m

Я не понимаю как unionfs поможет с сабжем.
Кстати, на тему глюков. Высока вероятность, что скоро unionfs будет совсем новая - http://people.freebsd.org/~daichi/unionfs/

Ivan8209

Не знаю, надо проверить.
Но со ссылками у CVS были какие-то проблемы.
---
...Я работаю...

Ivan8209

Архиватор может быть и правильный --- "rm".
---
...Я работаю...

Sharp

Я не понимаю как unionfs поможет с сабжем.

Имеется некоторый глобальный исходник. Дальше каждый его себе монтирует и правит. Причем, то что один что-то поправит у себя никак не повлияет на окружающих.
Вроде автор именно этого и добивается.

sergey_m

На такое описание похоже. Но на сабж непохоже. Может я тред невнимательно читал и в нём проясняется что к чему.

durka82

Имеется некоторый глобальный исходник. Дальше каждый его себе монтирует и правит. Причем, то что один что-то поправит у себя никак не повлияет на окружающих.

А в чем фишка?
Разве нельзя просто взять каждому по копии?
Или потом сливание будет осуществляться?
Тогда чем это отличается от версионного хранения?

Ivan8209

Оно будет более похоже, если научиться монтировать файл на файл.
---
...Я работаю антинаучным аферистом...

Sharp

Или потом сливание будет осуществляться?

Нет. То что было в основе, оно и останется. А те файлики, что каждый себе менял, будут измененными у них и храниться.

durka82

Ясно, спасибо, попробую

Olyalyau

Тебе нужна любая файловая система, поддерживающая линки (желательно символические) + скрипт, который из crona периодически запускается, ходит по файловой системе и отслеживает уникальность файлов (+их открытость в данный момент) и херит копии (для не открытых в данный момент устанавливая на их место линки.

durka82

желательно символические
Почему именно их? А еще какие бывают? (Я знаю еще только хардлинки)
Вообще из твоего описания не понятно, как будет реализована вторая часть этой схемы - когда отслеживается необходимость разнесения одного файла по двум...

Ivan8209

Не прокатит, и сразу очевидно, почему.
---
...Я работаю антинаучным аферистом...

Olyalyau

Почему именно их? А еще какие бывают? (Я знаю еще только хардлинки)

Софтлинки гибче, позволяют делать такую шнягу на нескольких файловых системах. Но можешь и хардлинки заюзать. Других линков я не знаю (разве что URI, но это уже из другой оперы).
Почему предлагаю делать скриптом из крона -- в рантайме у тебе не начнёт тормозить write или close, или куда там можно повесить процедуру поиска дубликата.
Вообще из твоего описания не понятно, как будет реализована вторая часть этой схемы - когда отслеживается необходимость разнесения одного файла по двум...

Чего непонятного? Библиотечный вызов open пропатчить и вот тебе счастье Тем более, что под современными файловыми системами (вроде ext3) можно сделать те самые расширенные атрибуты, в которые написать, как ты хочешь, атрибут "copy-on-write" или ещё чего. Можно и без расширенных атрибутов -- в любом случае у тебя будет структура для определения дубликатов (скорее всего сбалансированное или чёрно-красное дерево по какому-нибудь хешу. В этой же структуре можно и признак "copy-on-write" хранить. Вот только тогда придётся делать дополнительную тулзу для простановки этого признака, а так (если пользоваться расширенными атрибутами тулза уже есть.

Olyalyau

Не прокатит, и сразу очевидно, почему.

Напиши почему, чтобы очевидно стало и мне.

durka82

Спасибо, покопаю

Olyalyau

Ты чего, действительно собираешься open патчить?
А, понял, я там смайлик в нужном месте не поставил, сейчас поставлю

durka82

Еще не знаю.
Если решу, что это то, что мне надо - почему бы и нет...

Ivan8209

Что произойдёт, если сделать open(file,O_WRONLY) и туда написать?
---
...Я работаю антинаучным аферистом...

Ivan8209

open --- это очень небиблиотечный вызов.
Очень странно слышать такое от линуксоида.
---
...Я работаю антинаучным аферистом...

durka82

А как надо?

Ivan8209

Вообще-то open(2) --- это ядерный вызов.
---
...Я работаю антинаучным аферистом...

durka82

А поподробнее? Или где почитать?
А то это мне ни о чем не говорит

Ivan8209

Интерфейс ядра должен где-то быть описан.
Кто-то писал про программирование под Линукс на ассемблере.
---
...Я работаю антинаучным аферистом...

Olyalyau

Вообще-то open(2) --- это ядерный вызов
А поподробнее? Или где почитать?
А то это мне ни о чем не говорит

тебя обманывает
Он не читал POSIX. Там ясно написано, что open -- функция. А ни одного стандарта на системные вызовы нет.
В MINIX (POSIX-совместим начиная с некоторой версии например вообще нет системного вызова, выполняющего операцию открытия файла. Там есть три системных вызова "send" (послать сообщение "recv" (принять сообщение "send_recv" (послать сообщение и принять ответ -- чисто оптимизация, достаточно первых двух). А функция open формирует специальное сообщение и посылает его по определённому адресу -- менеджеру файловой системы.
В linux'е реализовано по другому, open является также библиотечной функцией, но просто обёртывающий соответствующий системный вызов.
Системный вызов -- программная точка входа в защищённый (аппаратным образом в современных процессорах) код ядра (выполняющийся в привилегированном кольце защиты) для выполнения операций, не доступных в непривилегированном кольце защиты, но необходимых запускающимся там приложениям. Может выполняться (на IA32, AMD-64) вызовом программного прерывания (инструкция int) или (последние процессоры) выполнением инструкции sysenter. Переписывать системный вызов -- означает переписывать (в случае open'а) файловую систему. И означает программирование в привилегированном кольце защиты, что является занятием не для слабонервных. Пропатчить библиотечную функцию open более простая задача.

Olyalyau

open --- это очень небиблиотечный вызов.

Вообще-то open(2) --- это ядерный вызов.
Читать POSIX до просветления

Olyalyau

Что произойдёт, если сделать open(file,O_WRONLY) и туда написать?
можно сделать те самые расширенные атрибуты, в которые написать, как ты хочешь, атрибут "copy-on-write" или ещё чего. Можно и без расширенных атрибутов -- в любом случае у тебя будет структура для определения дубликатов (скорее всего сбалансированное или чёрно-красное дерево по какому-нибудь хешу. В этой же структуре можно и признак "copy-on-write" хранить.
Пропатченый open должен читать признак "copy-on-write" из того места, где он будет храниться и поступать в соответствии. То есть при необходимости делать что-нибудь вроде "dd file /uniq_path/uniq_name", unlink (file link (/uniq_path/uniq_name, file unlink (/uniq_path/uniq_name open (file, ...) (и разумеется на file надо скопировать "copy-on-write" с оригинала). А, если "copy-on-write" не установлен, то просто open (file).
(dd взял в кавычки, чтобы не подумали, что это надо system("dd ...") сделать , разумеется надо реализовать функциональность dd без вызова внешних утилит, а то окажетесь Мюнхаузеном )
Если ты открыл файл на запись или чтение и запись, но файл не изменил (а в соответствии с "copy-on-write" файл скопировался при open'е) скрипт вернёт всё на место -- сольёт получившиеся два файла назад в один. Можно, конечно пропатчить и write с close'ом, но тогда на вскидку понадобятся дополнительные пляски с бубном вокруг имеющегося у этих функций inode и отсутствующего у них имени файла.

amkharchenko

Это называется, какой херней все страдали до изобретения fuse.

Ivan8209

И что это поменяет?
POSIX описывает механизм, по которому можно перехватить open?
"Пропатчить," как ты пишешь.
Покажи способ перехвата open(2 опираясь на этот самый POSIX.
---
...Я работаю антинаучным аферистом...

Ivan8209

> Пропатчить библиотечную функцию open более простая задача.
А если прикладное ПО полезет к open поверх этой идиотской обёртки?
---
...Я работаю антинаучным аферистом...

Sharp

А зачем это? Что, это стало модно, в проге реализовывать свой собственный open в обход библиотечого?
Да и вообще, нефиг лазить мимо библиотечных функций, так хрен какой совместимости добъешся.

Ivan8209

А зачем такой библиотечный вызов, который просто обёртка вокруг ядерного?
Двоичные форматы всё равно не совместимы, так что
с точки зрения совместимости обёртки ничего не дают.
---
...Я работаю антинаучным аферистом...

Sharp

Специально для KOHTPы прокомментирую.
Есть функция open и находится она в libc. Я не знаю, как точно она реализована, но я знаю, что она даст мне дескриптор. Каким образом она это сделает - мне не важно.
А писать свой собственный open для каждой системы, для каждой версии ядра - смысла нет.

Ivan8209

Есть вызов ядра open и нет смысла таскать огромадные glibc,
ради нескольких пустых оболочек вокруг вызовов ядра.
Все системозависимые функции принято определять в одном месте.
Расскажи, когда менялся интерфейс open? Приведи номера версий ядер.
---
...Я работаю антинаучным аферистом...

durka82

А что это?

sergey_m

Переписывать системный вызов -- означает переписывать (в случае open'а) файловую систему.
Вот это ты наврал.

amkharchenko

Filesystem in userspace ( web page). Вкратце --- существенно упрощает разработку собственных файловых систем (не надо задумываться о специфике ядра, пишется обычный userspace процесс, который использует библиотечку). Хотя, написание чего-то типа watchdog (т.е. не создающих новую ФС с нуля, а как-то подменяющих вызовы к существующей) весьма затруднено, хотя может быть выполнено с помощью индивидуальных mount в Linux.
Специфично для Linux. Возможно, аналоги есть в иных ОС.

Olyalyau

Если не рискнёшь писать непереносимую программу под конкретную OS то, например, вот:


LD_LIBRARY_PATH=/path/to/my/lib/with/my/own/open:$LD_LIBRARY_PATH

export LD_LIBRARY_PATH

Olyalyau

> Пропатчить библиотечную функцию open более простая задача.
А если прикладное ПО полезет к open поверх этой идиотской обёртки?

Проблемы возникнут только с непереносимым, не удовлетворяющим POSIX'у ПО. Причём сильно нарушающим POSIX. Я немного видел программ, которые лезут в syscall'ы не через описанные в POSIX интерфейсные функции, вроде того же open.

Olyalyau

А зачем такой библиотечный вызов, который просто обёртка вокруг ядерного?
Двоичные форматы всё равно не совместимы, так что
с точки зрения совместимости обёртки ничего не дают.

Вообще думал, что писал?
Для переносимости исходного кода. Чтобы одна и та же программа компилировалась и работала на разных системах. Для этого она должна использовать только описанные в общем для этих систем стандарте методы доступа к ресурсам. Застандартизировать syscall'ы нельзя, они уже на разном железе разные. По этому стандартизовали C-шные функции для доступа к ресурсам системы, по крайней мере на C тоже стандарт есть (для переносимости стандартизация должна быть полной, в том числе до уровня языка программирования).

Olyalyau

Расскажи, когда менялся интерфейс open? Приведи номера версий ядер.

Интерфейс системного вызова open меняется между Solaris, Ultrix, IRIX, Linux, QNX, MINUX, Haselnut/L4, etc. Более того, не у всех названных систем вообще есть системный вызов open. А вот функция open есть у всех них. И даже у Windos'а небось есть -- хоть там и кастрированный POSIX допотопной версии.

Olyalyau

Переписывать системный вызов -- означает переписывать (в случае open'а) файловую систему.
Вот это ты наврал.

Я имел в виду, что необходимость вмешаться именно в системный вызов (open) означает необходимость вмешаться в функционал сервисов OS (в данном случае, в файловую систему). Если нет необходимости править драйвер файловой системы, нет и необходимости лезть переписывать syscall.

Olyalyau

Тоже вариант, но для данной задачи я не вижу необходимости писать файловую систему или править код существующих. Скрипт + пропатченный open проще и безопаснее для данных. А то пока все баги в ФС выловишь, со столькими данными успеешь распрощаться Я когда-то давно, когда делать нечего было, реализовал ext2. Это заняло 2, если не 3 месяца. При этом: описание дисковой структуры ext2 было заранее известно, была тулза ext2.fsck, которая сильно помогала искать баги, и рисковать данными, монтируя рабочую ФС собственным драйвером я не стал

amkharchenko

Еще раз. Есть возможность писать на fuse watchdog-style файловые системы (сам такую написал . При этом, нет никакого смысла самому заниматься хранением файлов. Они будут содержаться в БД/обычной файловой системе. Именно этим fuse и хорош --- ну и еще тем, что можно на python писать.

Ivan8209

И как у тебя будут работать статически слинкованные программы?
---
...Я работаю антинаучным аферистом...

Ivan8209

Написание ядерного вызова не настолько сложно,
так что переносимость нисколько не страдает.
> для переносимости стандартизация должна быть полной,
> в том числе до уровня языка программирования
Если две системы похожи друг на друга как две капли воды,
то это _одна_ система, а не две.
О какой переносимости ты тогда говоришь?
---
...Я работаю антинаучным аферистом...

Olyalyau

Может это и будет работать, но я с fuse не сталкивался

Olyalyau

И как у тебя будут работать статически слинкованные программы?

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

Ivan8209

> Но статически слинкованные с libc программы попадаются крайне редко
Всё, что лежит в /sbin & /usr/sbin.
Таковы классические униксовые соглашения.
Кто первым вспомнил про соляру?
> предназначенные на случай ручного восстановления системы
Это вообще наглая ложь, потому что статически линкуют не для этого.
---
...Я работаю антинаучным аферистом...

Olyalyau

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

Переносимость и сложность программы -- разные понятия. Написание кода ядра сложно в отладке и чревато большими разрушениями в случае сбоев после отладки, чем изменение libc.
> для переносимости стандартизация должна быть полной,
> в том числе до уровня языка программирования
Если две системы похожи друг на друга как две капли воды,
то это _одна_ система, а не две.
О какой переносимости ты тогда говоришь?

Среди перечисленных мною систем
Solaris, Ultrix, IRIX, Linux, QNX, MINUX, Haselnut/L4

нет ни одной пары похожих друг на друга как две капли воды. Тем не менее хорошо написанная программа, удовлетворяющая POSIX может быть легко перенесена с одной из этих систем на другую. Это и есть переносимость.

Ivan8209

> Тем не менее хорошо написанная программа, удовлетворяющая POSIX
> может быть легко перенесена с одной из этих систем на другую.
> Это и есть переносимость.
Это не переносимость.
Это просто программа написана под платформу POSIX.
Вот и расскажи, как, опираясь на POSIX, сделать перехват всего, что будет выполнять open(2).
Не open(3 а именно open(2).
Хотя бы на Linux.
---
...Я работаю антинаучным аферистом...

Olyalyau

> Но статически слинкованные с libc программы попадаются крайне редко
Всё, что лежит в /sbin & /usr/sbin.
Таковы классические униксовые соглашения.
Кто первым вспомнил про соляру?
Какие такие соглашения? Что-то ничего такого в POSIX не видел.
Всё, что лежит в /sbin и /usr/sbin, говоришь?


# ls -1 /sbin | wc -l

308

# file /sbin/* | grep statically

 /sbin/busybox:                ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/cryptsetup:             ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/dmraid.static:          ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/dmsetup.static:         ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/dump:                   ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/e2fsck:                 ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/fsck.ext2:              ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/fsck.ext3:              ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/insmod.static:          ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV statically linked, stripped

/sbin/ldconfig:               ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/lvm.static:             ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/nash:                   ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV statically linked, stripped

/sbin/restore:                ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/rmt:                    ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/sash:                   ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/sbin/sln:                    ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, not stripped

/sbin/udev.static:            ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

# ls -1 /usr/sbin | wc -l

630

# file /usr/sbin/* | grep statically

/usr/sbin/build-locale-archive:                  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/usr/sbin/glibc_post_upgrade.i686:               ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/usr/sbin/libgcc_post_upgrade:                   ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

/usr/sbin/prelink:                               ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV for GNU/Linux 2.2.5, statically linked, stripped

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

Расскажи нам для чего.

Olyalyau

Вот и расскажи, как, опираясь на POSIX, сделать перехват всего, что будет выполнять open(2).
Не open(3 а именно open(2).

Уже писал. Не для всего, но для всего, что будет реально использоваться. А в связи с идеей
задействовать fuse, даже моё предложение теряет актуальность, не говоря уж о бреде переписывания syscall'а.

Ivan8209

> GNU/Linux 2.2.5
Кто первым вспомнил о соляре и других осях?
Статически линкуют для того, чтобы не быть зависимым от внешних библиотек.
А причины для этой независимости могут быть самыми разными.
Я уж не говорю, что вот это
> из предположения некорректного функционирования системы
> и берётся необходимость собирать их статически
вообще идёт по ложному пути.
Если кто-то смог побить libc, то он точно так же мог побить и /sbin,
а ремонтная система вполне может работать и с ремонтной версией libc.
---
...Я работаю антинаучным аферистом...

Ivan8209

>> Не open(3 а именно open(2).
> Уже писал.
Ты не умеешь читать?
Цифры "2" и "3" различаешь по написанию?
Первая же статически слинкованная программа побьёт твою систему.
Хочешь сказать, что POSIX не допускает статически слинкованные программы?
На то, что будет реально использоваться, ты накладываешь очень жёсткие условия,
в реальной жизни, в частности, в условиях поставленной задачи, почти невыполнимые.
---
...Я работаю антинаучным аферистом...

Olyalyau

> GNU/Linux 2.2.5
Кто первым вспомнил о соляре и других осях?

Я просто привёл пример системы, под которой нарушается заявленное тобой про статически слинкованные проги:
Всё, что лежит в /sbin & /usr/sbin.
Таковы классические униксовые соглашения.

А остальные ОСи -- ну может они тебе и помогут: если найдёшь среди них, ту под которой всё что там лежит скомпилено статически -- сможешь себя частично реабилитировать.
Кстати, статически слинкованные проги тоже больших проблем не вызывают, если есть исходники к ним. Надо просто перекомпилировать их с пропатченной libc -- и вот тебе счастье.

Olyalyau

>> Не open(3 а именно open(2).
> Уже писал.
Ты не умеешь читать?
Цифры "2" и "3" различаешь по написанию?

Почему вы так старательно предлагаете мне то, что я предлагал автору треда? Читаем man 2 open:


OPEN(2)                        System calls                        OPEN(2)

NAME

       open, creat - open and possibly create a file or device

SYNOPSIS

       #include <sys/types.h>

       #include <sys/stat.h>

       #include <fcntl.h>

       int open(const char *pathname, int flags);

       int open(const char *pathname, int flags, mode_t mode);

       int creat(const char *pathname, mode_t mode);

И видим 2 С-шные функции (именно две, а не три, С-шные функции различаются по именам, а не по имя+сигнатура одну из которых я и предлагал пропатчить -- open, у неё здесь 2 сигнатуры.
Читаем дальше:
 DESCRIPTION

       The  open  system  call is used to convert a pathname into a file

       descriptor (a small, non-negative integer for use in subsequent I/O

       as  with read, write, etc.).

Ах вот оно что, слова "system call" производят переполох в юных, неокрепших умах
, включи мозг и попробуй подумать каким это образом syscall может быть именован, если архитектура процессора этого не позволяет?
Смотрим fcntl.h:


#ifndef __USE_FILE_OFFSET64

extern int open (__const char *__file, int __oflag, ...) __nonnull 1;

#else

# ifdef __REDIRECT

extern int __REDIRECT (open, (__const char *__file, int __oflag, ... open64)

     __nonnull 1;

# else

#  define open open64

# endif

#endif

#ifdef __USE_LARGEFILE64

extern int open64 (__const char *__file, int __oflag, ...) __nonnull 1;

#endif

Делаем
 $ objdump -x /lib/libc.so.6 | grep open64

Кроме прочей лабуды видим два символа, ссылающихся на один адрес:


000b9a80  w    F .text  000000ba              open64

000b9a80  w    F .text  000000ba              __open64

Делаем: 


$ objdump -d /lib/libc.so.6 | grep -A 70 000b9a80

и по адресу b9acd наконец-то видим syscall (int $0x80 также видим кучу лабуды, относящуюся к open(2) -- обёртке этого syscall'а:
 000b9a80 <__open64>:

   b9a80:       55                      push   %ebp

   b9a81:       b8 00 00 00 00          mov    $0x0,%eax

   b9a86:       89 e5                   mov    %esp,%ebp

   b9a88:       83 ec 14                sub    $0x14,%esp

   b9a8b:       89 75 f8                mov    %esi,0xfffffff8(%ebp)

   b9a8e:       8b 75 0c                mov    0xc(%ebp%esi

   b9a91:       89 5d f4                mov    %ebx,0xfffffff4(%ebp)

   b9a94:       e8 b8 b6 f5 ff          call   15151 <__i686.get_pc_thunk.bx>

   b9a99:       81 c3 5b e5 06 00       add    $0x6e55b,%ebx

   b9a9f:       89 7d fc                mov    %edi,0xfffffffc(%ebp)

   b9aa2:       f7 c6 40 00 00 00       test   $0x40,%esi

   b9aa8:       8b 93 10 2a 00 00       mov    0x2a10(%ebx%edx

   b9aae:       0f 45 45 10             cmovne 0x10(%ebp%eax

   b9ab2:       8b 7d 08                mov    0x8(%ebp%edi

   b9ab5:       85 d2                   test   %edx,%edx

   b9ab7:       89 45 ec                mov    %eax,0xffffffec(%ebp)

   b9aba:       75 2d                   jne    b9ae9 <__open64+0x69>

   b9abc:       81 ce 00 80 00 00       or     $0x8000,%esi

   b9ac2:       89 c2                   mov    %eax,%edx

   b9ac4:       89 f1                   mov    %esi,%ecx

   b9ac6:       87 df                   xchg   %ebx,%edi

   b9ac8:       b8 05 00 00 00          mov    $0x5,%eax

   b9acd:       cd 80                   int    $0x80

   b9acf:       87 fb                   xchg   %edi,%ebx

   b9ad1:       3d 00 f0 ff ff          cmp    $0xfffff000,%eax

   b9ad6:       89 c6                   mov    %eax,%esi

   b9ad8:       77 40                   ja     b9b1a <__open64+0x9a>

   b9ada:       89 f0                   mov    %esi,%eax

   b9adc:       8b 5d f4                mov    0xfffffff4(%ebp%ebx

   b9adf:       8b 75 f8                mov    0xfffffff8(%ebp%esi

   b9ae2:       8b 7d fc                mov    0xfffffffc(%ebp%edi

   b9ae5:       89 ec                   mov    %ebp,%esp

   b9ae7:       5d                      pop    %ebp

   b9ae8:       c3                      ret

   b9ae9:       e8 a2 c9 01 00          call   d6490 <__librt_enable_asynccancel>

   b9aee:       89 45 f0                mov    %eax,0xfffffff0(%ebp)

   b9af1:       81 ce 00 80 00 00       or     $0x8000,%esi

   b9af7:       8b 55 ec                mov    0xffffffec(%ebp%edx

   b9afa:       89 f1                   mov    %esi,%ecx

   b9afc:       87 df                   xchg   %ebx,%edi

   b9afe:       b8 05 00 00 00          mov    $0x5,%eax

   b9b03:       cd 80                   int    $0x80

   b9b05:       87 fb                   xchg   %edi,%ebx

   b9b07:       3d 00 f0 ff ff          cmp    $0xfffff000,%eax

   b9b0c:       89 c6                   mov    %eax,%esi

   b9b0e:       77 1a                   ja     b9b2a <__open64+0xaa>

   b9b10:       8b 45 f0                mov    0xfffffff0(%ebp%eax

   b9b13:       e8 e8 c9 01 00          call   d6500 <__librt_disable_asynccancel>

   b9b18:       eb c0                   jmp    b9ada <__open64+0x5a>

   b9b1a:       f7 de                   neg    %esi

   b9b1c:       e8 ef ba f5 ff          call   15610 <__errno_location>

   b9b21:       89 30                   mov    %esi%eax)

   b9b23:       be ff ff ff ff          mov    $0xffffffff,%esi

   b9b28:       eb b0                   jmp    b9ada <__open64+0x5a>

   b9b2a:       f7 de                   neg    %esi

   b9b2c:       e8 df ba f5 ff          call   15610 <__errno_location>

   b9b31:       89 30                   mov    %esi%eax)

   b9b33:       be ff ff ff ff          mov    $0xffffffff,%esi

   b9b38:       eb d6                   jmp    b9b10 <__open64+0x90>

   b9b3a:       90                      nop

   b9b3b:       90                      nop

   b9b3c:       90                      nop

   b9b3d:       90                      nop

   b9b3e:       90                      nop

   b9b3f:       90                      nop

000b9b40 <__close>:

...........................................

Прямо перед int $0x80 видим:


   b9ac2:       89 c2                   mov    %eax,%edx

   b9ac4:       89 f1                   mov    %esi,%ecx

   b9ac6:       87 df                   xchg   %ebx,%edi

   b9ac8:       b8 05 00 00 00          mov    $0x5,%eax

   b9acd:       cd 80                   int    $0x80

Во втором варианте:
 

   b9af7:       8b 55 ec                mov    0xffffffec(%ebp%edx

   b9afa:       89 f1                   mov    %esi,%ecx

   b9afc:       87 df                   xchg   %ebx,%edi

   b9afe:       b8 05 00 00 00          mov    $0x5,%eax

   b9b03:       cd 80                   int    $0x80

Sharp

я уже бросил затею, довести что-нить до сознания KOHTPы, а ты не поленился.
Респект.
Но моя практика показывает, что когда приводятся неоспоримые аргументы, KOHTPа начинает гнать какую-то фигню и переводит разговор в другое русло.

Olyalyau

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

Ivan8209

> если есть исходники к ним.
А если нет?
---
...Я работаю антинаучным аферистом...

Ivan8209

Ты выбрал Си.
Так вот. Выкинь Си к чёрту.
Объясни, начерта писать обёртку, если можно сразу встраивать вызов ядра?
И незачем ссылаться на кривизну компилятора сей.
---
...Я работаю антинаучным аферистом...

Olyalyau

> если есть исходники к ним.
А если нет?

А это вопрос к автору треда -- пользуется ли он такими программами. Кроме того, предложил использовать fuse, вот fuse и будет использоваться, если автору треда нужны такие программы.

Olyalyau

Ты выбрал Си.
Так вот. Выкинь Си к чёрту.
Ничего не выбирал Сделал всё в точности, как написано в open(2 который тоже не я выбрал, а ты
Объясни, начерта писать обёртку, если можно сразу встраивать вызов ядра?
И незачем ссылаться на кривизну компилятора сей.
А ты знаешь компилятор, который кодогенерит int или sysenter, а не берёт их из библиотек или define'ов? Приведи пример такого компилятора. Это будет новое слово в науке и технике

Olyalyau

Ты был прав, КОНТРу понесло мимо темы

Ivan8209

Этот компилятор не настолько сложно написать. Я такое делал.
Наверняка это уже есть и в промышленных системах.
---
...Я работаю антинаучным аферистом...

Ivan8209

Итого, переписывание open(3) задачу не решает.
---
"Истина грядёт --- её ничто не остановит!"

Olyalyau

Этот компилятор не настолько сложно написать. Я такое делал.
Тебе остаётся только дать 'у свой компилятор, чтобы было ему счастье

Olyalyau

Итого, переписывание open(3) задачу не решает.

Это ты к чему? Я open(2) переписывать предлагаю, а про open(3) -- это всё ты сам придумал
Оставить комментарий
Имя или ник:
Комментарий: