создать файловую систему

Вирус пишешь?

1) забудь слово «папка». В файловой системе содержатся каталоги, а не папки. 2) см. FUSE (Filesystem in User-Space) — это наиболее простой способ

лисапед? :)

>FUSE

или v9fs

>каталоги, а не папки

директории ;)

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

Просто, когда это писал, как раз вспоминал, как люди объединяли в офтопике две _папки_ в active directory через data trasnformation services в MS SQL.

Кому интересно, зачем это надо - отвечаю просто. Хочу написать обратимый макропроцессор. Редактируешь файл с макросами - получаешь новую версию файла с расширенными макросами. И наоборот - из файла с расширенными макросами можно получить обратно версию со свёрнутыми.

Помимо того, что это удобно, это позволяет решить организационную проблему. Люди не любят макросы и не понимают их. Они предпочитают писать много кода, там, где надо писать мало. В проектах я сталкивался с проблемами, когда я попытался внедрить m4 (куски кода сокращались при этом по объёму вдвое и втрое). Люди не смогли у себя поставить m4 и/или просто ничего не поняли.

Поэтому я хочу сделать отображение на уровне файловой системы. В одном каталоге лежит файл с "раскрытыми" макросами, а в другом - с "ужатыми". На самом деле - это два вида одного и того же файла.

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

Ну и, например, так можно напускать макропроцессоры на java, которая их не особо хорошо понимает.

Если бы нужно было преобразование только в одну сторону - хватило бы обычного макропроцессора. А так - не хватит.

Делаться всё это будет на Common Lisp. Ну и сам язык макросов - тоже будет Common Lisp.

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

Круто, FUSE понравилось.

а в cvs в каком виде исходники лежать будут - с развернутыми макросами (как народ хочет) или со свернутыми (как ты хочешь)? Если 1-й вариант, то легче сделать конвертер на этапе commit/update: типа ты правишь файлы с макросами, а коммитишь без - народ доволен; при апдейте - макросы распознаются и сворачиваются - ты доволен, если 2-й, то какого х начальник хочет чего-то править? Пусть учит m4 :)

Насчет перехватывания событий директории - так это можно демона (shell-скрипт?) повесить, который будет раз в секунду проверять изменения.

>Кстати, я понял, что мне достаточно более простой вещи - нужно всего лишь перехватить события самой директории: создание файла, изменение файла, изменение даты.

так ведь для этого и inotify хватит.

>создать файловую систему

Женат?

Так, всё совсем круто. Inotify, наверное, хватит. Хотя ещё не понял. С FUSE, видимо, будет всё же понадёжнее.

Личной жизнью доволен. А вот профессиональной - нет. Вообще-то на лиспе чудеса делаются в такие сжатые сроки, что им даже перестаёшь удивляться. Судя по интерфейсу FUSE, создать работоспособную файловую систему можно, я так думаю, дня за два-три. Раз я так думаю, то реально она разрабатывается недели за две-три. Ну и к тому же это нужно не для баловства, а для реальной работы. Я к этой проблеме подходил уже со всех сторон, пробовал на практике и вижу, что именно так она решается лучше всего.

Насчёт CVS. Я думал об этом, но есть такие проблемы с этим подходом: 1. Даже на С мне нужно будет иметь расширенные файлы на диске во время сборки. Получается дублирование механизмов - при записи в CVS я делаю то же, что и при сборке. И, видимо, в CVS будет лежать оба варианта. Т.к. обратное сворачивание макросов - это задача тяжелая, иногда вообще не решаемая и следует избегать случаев, когда её приходится применять. Соответственно, нужно вести историю обоих версий. 2. При сборке мне нужно иметь содержимое расширенного файла от прошлой сборки. Макрорасширитель/сжиматель будет работать примерно по принципу merge в системах контроля версий (тут ты правильно вспомнил про CVS). Но фишка ещё и в том, что макры не обязаны быть "функционально чистыми". Они могут, к примеру, лезть на SQL сервер и получать метаданные таблицы, из которых и строить своё расширение. Поэтому я буду генерировать сначала временный расширенный файл и сравнивать его со старым расширенным файлом. Если ничего не изменилось (никто не альтерил таблицу), то и трогать его незачем. Это экономит море времени на сборке (реально без этого пользоваться почти невозможно, особенно в случае С++, и я уже это проверил на практике). Попутно отпадает необходимость отслеживать взаимозависимости самих макр и смотреть, какая макра в каком файле используется. Просто тупо расширяем все файлы всеми макрами (это быстро), а потом выбрасываем лишнюю работу.

>> лисапед? :)

а то

можно почитать :
Файловая система UNIX : Эволюция , разработка и реализация

Автор : Steve D.Pate

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

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

Распознавание высокоуровневых конструкций (в таком ракурсе) это очень интересно. Но вот fuse как средство борьбы с __тупым__ начальником -- это... ну очень сомнительно.

Макросы программистами воспринимаются с опасением из-за того, что в них нет проверки типизации, и даже шаблоны в стиле С++ (не явы, не С++0х) местами совершенно недостаточно надежны.

FUSE? или PhysFS http://icculus.org/physfs/ ?

Недостаточно проработанные макросы будут костымями и "магией" (хотя я иногда этим пользуюсь).

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

Inotify , http://ru.wikipedia.org/wiki/Inotify

Так что выход тут только в создании и вылизывании (макро)системы.

типа Make http://www.programming.nu/nuke

посмотри ещё LISFS, http://aryx.kicks-ass.org/~pad/papers/lisfs-demo-icse06.pdf http://www.xent.com/pipermail/fork/Week-of-Mon-20030721/024170.html http://portal.acm.org/citation.cfm?id=1134418 http://www.irisa.fr/activity/new/007/logicalinformationsystems012?set_languag...

http://hal.inria.fr/view_by_stamp.php?label=INRIA-RRRT&action_todo=view&a...

> Судя по интерфейсу FUSE, создать работоспособную файловую систему можно, я так думаю, дня за два-три.

уже, и кстати, на FUSE http://lfs.irisa.fr/download/

мне кажется, или Луговской, не к ночи будь помянут, действительно занимался чем-то таким вроде LISFS для пакетных менеджеров, применительно к Alt.Linux и Окамлю? http://rpm.pbone.net/index.php3/stat/4/idpl/1960778/com/findlib-0.8-alt1.i586...

Про nuke:

> Unlike make and rake, nuke doesn't support rules, so build tasks are created by looping over the necessary files. Also, nuke doesn't yet have a way to extract and include header file dependencies, but generated dependencies can be easily added with lines like the following one

По-моему, это средство самим своим существованием позорит лисповый синтаксис.

Спасибо за ссылки на LISFS, посмотрел, увидел огромный и плохо документированный код. Наверное, проще написать самому. У меня нет таких уж больших требований. Мне всего лишь нужно сделать интерфейс fuse-common lisp, а дальше уже легко.

www_linux_org_ru, у тебя ИМХО слишком большая страсть к типизации.

ещё ссылки на тему около LISFS: http://nixos.org/docs/papers.html
про функциональный аналог Make навевает интересные мысли статья про конфигурационное управление