Ф.С.
Зараннее предупраждаю.. На данный момент это вопрос рассматривается скорее как зарядка для ума, хотя в будущем - мало ли... ;)
Некоторое время назад (в очередной раз :)) возникла бредовая мысль слепить ф.с. в основе которой будет не дерево, а граф, т.е. файл, кроме самого себя, может содержать произвольное число связей на другие файлы. (каталог - это, по сути, файл без содержимого)
Но возник ряд вопросов, по поводу которых хотелось бы услышать мнение:
1. имеет ли это смысл вобще? (для меня - имеет, но сейчас не обо мне речь :))
2. Поскольку понятие "абсолютного пути" тут тряет смысл, то как адресовать файл расположенный не в корне? Можно (нужно!) конечно вести историю посещённых каталогов, но после десятка-двух перемещений путь до корня по ней установить проблематично...
3. Удаление файла.. Тут вобще фиг знает что. Помнится давным-давно, в ДОСе ещё, проводил подобный эксперемент.. Результат странный.. Да и вобще, удалить файл, на который имеется много ссылок - тоже вопрос.. Только полным просмотром всего диска?
4. Копирование. В общем - примерно то же самое, что и с удалением..
5. Поиск. Тут тоже непонятки.. как ограничить поиск определённым регионом?
6. Навигация вобще.. Дерево тут уже не построишь
7. и самое интересное: как всё это уложить на диск :)
ЗЫ: Не подскажите, где можно глянуть описание различных ф.с.? (кроме FAT-a)
В смысле - подробное, пригодное для написания программы, работающей с ними.. А то попадаются только в общем виде..
:???:
А какие именно "графы" ты имеешь в виду:
ориентированные, сети Петри... и.т.д.?
Если я тебя правильно понял, то в файловой системе на базе графов, даже не в каталогах, а в обычных файлах будут ссылки на остальные файлы?... И при этом всё это будет представлять из себя сложнейшую систему, где каждая вершина графа (элемент графа) будет связана с тысячами остальных...
Вопрос: А зачем это надо? Что оно улучшает?
Если представить программную реализацию всего этого, то этот "вид" файловой системы будет неоправдано ресурсоёмкий... Будет занимать раз в 10 больше дискового пространства, чем все существующие... X)-
ориентированные, сети Петри... и.т.д.?
Я плохо помню теорию.. Но смысл такой, что ссылок на верх нет. Только вниз.
Именно
Ну зачем же с тысячами.. Нет, если очень хочется, то можно и так, но предпологается, всё-таки более скромный подход..
Улучшает оно, собственно, только одно: поиск файлов по смыслу.
Собственно, идея появилась, когда пришлось сортировать файлы по какому-либо признаку.. Зачастую файл мог попасть в несколько категорий сразу. А тут просто создал в файле линк на другой файл, содержащий близкую по теме инфу..
Изначально была мысль просто добавить к файлу ещё один поток (NTFS вроде это умеет делать) с описанием/ключевыми словами.. (кстати, эта структура вполне дозволяет и такое, ведь файл можно создать и внутри другого файла)
Вот только как ограничить содержимое файла так, что бы при его копировании не уползали посторонние файлы?
На самом деле просьба камнями не кидать.. я сам прекрасно понимаю, что это гораздо легче делается с помошью баз данных. Вот только хотелось бы без них.. Минимум постороннего софта.
Вот как раз это я и пытаюсь сделать :)
Пока - именно представить...
Ну, насчёт 10 раз - это перебор..
Чуть больше - это да.. Это будет.. Но не сильно.
Кто сказал, что для каждого файла ОБЯЗАТЕЛЬНО создавать отдельный каталог? (нет у него ссылок - и не надо)
И кто сказал, что для каждого файла обязательно создавать ОТДЕЛЬНЫЙ каталог? Можно создать один, на группу, и уж если он слишком расползется - разделить.. По необходимости..
Тоесть получается, что тут будет файловая иерархия. Удаляешь один файл - и при этом удаляется ещё несколько нижележащих файлов, на которые есть ссылки у данного файла... Это так?
А по каким признакам будет определяться эта "файловая иерархия"? Как будет определяться к каким остальным элементам графа нужно будет присоединять новый файл?
Ты ведь ещё сказал, что каталогов не будет... Но что же из себя будет представлять самый высший по иерархии элемент графа, так сказать корневой элемент графа, -- помоему это и будет корневым каталогом, удаляешь его и при этом удаляются сразу все остальные файлы.
Некоторое время назад (в очередной раз :)) возникла бредовая мысль слепить ф.с. в основе которой будет не дерево, а граф, т.е. файл, кроме самого себя, может содержать произвольное число связей на другие файлы. (каталог - это, по сути, файл без содержимого)
Ну а чем эта ФС отличается от Ext2, NTFS, где так же есть жесткие ссылки?
Тоесть получается, что тут будет файловая иерархия. Удаляешь один файл - и при этом удаляется ещё несколько нижележащих файлов, на которые есть ссылки у данного файла... Это так?
Да вот собственно в этом и проблема.. Одна из. Один файл может принадлежать сразу нескольким другим, и удалять его, в это случае...?
Видимо, надо 2 режима удаления: Текущщей сылки на файл (если их больше одной) и файла физически (с чисткой всех ссылок на него. Вот только искать их.. :()
Тут всё как обычно: в каком каталоге (файле) создаешь файл - туда и линкуется. Дополнительные же ссылки можно создавать отдельным механизмом, типа создания ссылок в ext2
Ладно. Один каталог будет. Но это лишь очень частный случай, далекий от общих проблем..
Ну а чем эта ФС отличается от Ext2, NTFS, где так же есть жесткие ссылки?
Тем, что ссылки будут не в каталогах, а в файлах.
Кстати, действительно, был вариант написать имитацию этой фс используя каталоги и ссылки. Для тестирования...
Файловая система -- FAT. Просто FAT.
Далее, по старой памяти ДОС, мы пишем дровицу типа APPEND, которая умеет читать расширенную запись-линк. Расширенная запись-линк -- это что-то вроде расширенной записи-лонгнейма, но в своей текстовой "голове" содержит не только имя, но и более-менее относительный или абсолютный путь к реальному файлу, нулевую длину и все нули в кластерах, а также специальный флаг атрибута.
Дровица наша отображает в каталог, где такой линк найден, в прозрачном режиме сам соответствующий ему файл. При открывании открывается оригинал, а при стирании стирается, естественно, только линк.
Таким образом, система гиперссылок позволяет загнать полпрограммы на какой-нибудь DVD, освободив место на диске, а в каталоге установки просто набить кучу гиперлинков на оригиналы.
В случае же, если оригинальный диск извлечен (или просто мы стерли сам "настоящий" файл) при попытке открытия линка дровица возвращает программе стандартную ошибку открытия (что-то типа "диск не готов"), а это уж ее дело обрабатывать ошибки.
Совместимость с FAT полная (I/O без нашей дровицы не чревато нарушением системы гиперссылок), а удобство весьма высокое, ибо в древовидном графе запутаться сложно %)
Со своей стороны пускаю мазу воткнуть в дровицу динамический UNRAR и заткнуть за пояс ZipMagic и DrvSpace вместе взятые %) Ессно, открывать ссылки, ведущие внутрь RAR'а, она будет только в режиме чтения... Ну и довольно с нее %)
Не очень понимаю какая тут зависимость от файловой системы.
Пусть файл будет файлом. А где-то в другом месте пусть хранится структура графа.
А вообще-то, зачем нужен такой граф? Чем плоха иерархия?
В корне - темы (по сути - обычные каталоги). В темах - подтемы (то бишь подкаталоги). Доступ к любой группе файлов начинается с корня. Если файл хочется искать в разных темах - создаются соответствующие отростки дерева (можно так: карандаш - грифель - уголь - углерод - атомы - электроны /// а можно и так: Химия - молекулы - атомы ... (причем Химия и Карандаш - в корне, а в темах Углерод и Молекулы есть ссылка на Атомы, причем сама тема Атомы не дублируется)). Разумеется, в темах (т.е. каталогах) должны храниться только ссылки на файлы. А файлы при этом живут паралельно сами по себе - в любой ФС. Т.е. информация для поиска файла является просто довеском и не влияет на ход вещей, пока какой-то специальный файловый менеджер не захочет к ней обратиться. Причем вся информация для поиска может храниться хоть в отдельном файле, хоть как-то еще - это для идеи не существенно.
Поисковая структура может дополняться при каждом новом запросе.
Пример:
Хочу найти описание диалога процессора с контроллером дисковода при чтении сектора (подразумевается обмен через порты).
Ищу в корне: контроллер. Опа! Нету в корне такой темы!!! А система уже потихоньку ее создает... Ну, может сначала подтверждение попросит.
Пробую иначе: дисковод. Есть такая тема в корне. Заходим в нее. А там ссылочки на подтемы. Я говорю: порты. Облом! (но система уже добавляет сюда такую подтему) Я говорю: контроллер. Есть такая подтема. Заходим. О! А вот в ней и файл который мне нужен (например ссылочка на какой-нибудь D:\path\filename.ext).
Проблема одна.
Как связать файл с темами? Точнее - КТО должен это делать?
В рамках иерархии все понятно: вассал моего вассала - МОЙ (!) вассал. Т.е. если папа общий, то дедушка и подавно.
Но если создается НОВАЯ тема, то КТО скажет как должны быть классифицированы файлы в ней?
Или если я создал новых файл про уголь мне (системе) надо догадаться куда его поместить в иерархии. То ли в список топлива, в котором тут же будет нефть и газ. То ли в другой какой-нибудь список. А вообще-то надо сразу в несколько...
%-)
Итог: как, в каком виде и где хранить структуру (графа, дерева или чего еще)- не проблема. Проблема - как ее заполнять! Ведь каждый файл надо отнести к какой-то группе и не к одной!!!
А если связывать файл с файлом, то смысл легко потерять. Связал КОРЕНЬ с ВЕРШИНОЙ, СТЕБЛЕМ или СТВОЛОМ - а КОРЕНЬ был КВАДРАТНЫЙ от отрицательного числа.
Ну, допустим, точно известен смысл файла КОРЕНЬ. Это про дерево. Связали с КРОНОЙ. Теперь можно найти этот файл в каталоге ДЕРЕВО. Но это простая иерархия. А если я при поиске буду искать не корень, как часть дерева, а корень как часть сосны? Значит надо предусмотреть, что бы файл (ссылка) попал и в этот каталог, и чтобы в нем было все ТОЛЬКО про сосны.
Для обеспечения ДЕЙСТВИТЕЛЬНО УДОБНОГО (смыслового) поиска надо хранить структуру ДЕЙСТВИТЕЛЬНО БОЛЬШОГО размера. И у каждого последующего элемента структуры будет больше связей, чем у предыдущих.
По моему это просто связь Многие-Ко-Многим.
P.S.: Я в Интернете хочу найти документ, но переходя по ссылкам, наверное можно искать долго. А потом окажется, что этот документ не связан с данным графом вовсе...
Может система не так уж хороша? Для идеального поиска вообще надо бы хранить ВСЕ атрибуты для каждого файла (т.е. относится ли он к программам, документам, ..., про дерево или нет, про животных или нет,....), и при появлении нового атрибута врисваивать ему правильное значение у каждого файла. О размерах структуры просто молчу...
Извиняюсь что так объемно.
Особенно если еще и не в тему...
Вот ИМНСХО оптимальный вариант.
Не катит...
Ещё раз повторяю:
1. Идея - привязывать не файлы к каталогам, а файлы к файлам.
2. Целостность. СофтЛинки - это конечно хорошо, но тут ничего новго придумывать не надо, всё это есть в ext2. А в твоем варианте - бардак. Если я удаляю файл из одного каталога, то в другом он должен остаться.. А не превратиться во что-то типа "диск не готов".
3. Кстати, если не ошибаюсь, ZipMagic и DrvSpace позволяют и писать в архив (второй - просто по определению). :)
Поиск информации по смыслу - это вообще интересно.
Не очень понимаю какая тут зависимость от файловой системы.
Пусть файл будет файлом. А где-то в другом месте пусть хранится структура графа.
Нет, смысл как раз в том, что бы не использовать лишний софт.
Возможно я не прав, но я предпочитаю наиболее общедоступные решения, в том смысле, что если накроется система связи файлов с описанием графа(даже при наличии всего 1..2 сотен файлов) - в этой куче уже разобраться занятие сомнительной привлекательности.. А ведь при нынешних обьёмах дисков счёт идет на тысячи, а то и десятки тысяч..
Если же всё это работает на уровне файловой системы, то если ты смог просто загрузить систему - тебе УЖЕ доступна все данные в том виде, в котором ты можешь с ними работать.
В корне - темы (по сути - обычные каталоги). В темах - подтемы (то бишь подкаталоги). Доступ к любой группе файлов начинается с корня. Если файл хочется искать в разных темах - создаются соответствующие отростки дерева (можно так: карандаш - грифель - уголь - углерод - атомы - электроны /// а можно и так: Химия - молекулы - атомы ... (причем Химия и Карандаш - в корне, а в темах Углерод и Молекулы есть ссылка на Атомы, причем сама тема Атомы не дублируется)). Разумеется, в темах (т.е. каталогах) должны храниться только ссылки на файлы. А файлы при этом живут паралельно сами по себе - в любой ФС.
Ты сам ответил на свой вопрос. В дереве ветви не могут пересекаться и срастаться вновь..
Ну и ещё раз повторюсь - основная идея организовать управление всей системой на максимально низком уровне, что бы не разгребать файлы в случае повреждения базы с описанием.
Вобще же такой вариант уже рассматривался (я не зря в одном из сообщений уже упоминал базы данных.. На их основе такая система делается без особого напряга и ребёнком, но это не то..)
Поисковая структура может дополняться при каждом новом запросе.
Пример:
Хочу найти описание диалога процессора с контроллером дисковода при чтении сектора (подразумевается обмен через порты).
Ищу в корне: контроллер. Опа! Нету в корне такой темы!!! А система уже потихоньку ее создает... Ну, может сначала подтверждение попросит.
Пробую иначе: дисковод. Есть такая тема в корне. Заходим в нее. А там ссылочки на подтемы. Я говорю: порты. Облом! (но система уже добавляет сюда такую подтему) Я говорю: контроллер. Есть такая подтема. Заходим. О! А вот в ней и файл который мне нужен (например ссылочка на какой-нибудь D:\path\filename.ext).
Идея интересная.. Вобще то я не пытался создать аналог базы знаний, который бы сам давал информацию (еще раз напомню - минимум лишнего софта:)), но в переспективе - это как раз и должно получиться.
Как связать файл с темами? Точнее - КТО должен это делать?
В рамках иерархии все понятно: вассал моего вассала - МОЙ (!) вассал. Т.е. если папа общий, то дедушка и подавно.
Но если создается НОВАЯ тема, то КТО скажет как должны быть классифицированы файлы в ней?
Или если я создал новых файл про уголь мне (системе) надо догадаться куда его поместить в иерархии. То ли в список топлива, в котором тут же будет нефть и газ. То ли в другой какой-нибудь список. А вообще-то надо сразу в несколько...
%-)
Итог: как, в каком виде и где хранить структуру (графа, дерева или чего еще)- не проблема. Проблема - как ее заполнять! Ведь каждый файл надо отнести к какой-то группе и не к одной!!!
А если связывать файл с файлом, то смысл легко потерять. Связал КОРЕНЬ с ВЕРШИНОЙ, СТЕБЛЕМ или СТВОЛОМ - а КОРЕНЬ был КВАДРАТНЫЙ от отрицательного числа.
Ну, допустим, точно известен смысл файла КОРЕНЬ. Это про дерево. Связали с КРОНОЙ. Теперь можно найти этот файл в каталоге ДЕРЕВО. Но это простая иерархия. А если я при поиске буду искать не корень, как часть дерева, а корень как часть сосны? Значит надо предусмотреть, что бы файл (ссылка) попал и в этот каталог, и чтобы в нем было все ТОЛЬКО про сосны.
На данном этапе предпологается создавать связи вручную.. Просто указать, какой файл куда цеплять..
Вопрос тут в глубине ссылок. Точнее - в их детализации. Т.е. если для каждого файла с чуть отличными свойствами - создавать новый каталог - то действительно можно использовать и систему, в которой просто будут добавляться линки на файлы (ту, скорее, на каталоги)
Если-же на одном уровне будут храниться файлы с несколько различными свойствами - тут уже больше подходит моя схема, связей файлов с файлами..
Наглядный пример: публикации нескольких авторов по нескольким темам.. Получить либо список авторов по одной теме, либо список тем одного автора..
Заходишь в файл - а там 2 каталога: публикации по теме и публикации этого автора.
Хотя согласен, поддерживать такую систему вручную - дело тяжкое, и при большой скорости поступления документов - совсем нереальное. Тут уже действительно нужна автоматическая система...
Кстати, в ситуации с "корнем" достаточно просто провести статистический анализировать текста на предмет наличия там специфических терминов и выбрать раздел, в котором больше попаданий. Вероятность угадать правильно достаточно велика - у каждой науки свои заморочки.
По моему это просто связь Многие-Ко-Многим.
Не совсем понял, почему больше? Каждый элемент указывает только на несколько узлов, в которые он попадает. Связи между узлами мегут быть сложнее в целом, но их на порядок (порядки?) меньше.
Файл не может "не быть связанным" с ф.с. Такой файл не существует для о.с. Так-же, как ни один поисковик никогда не найдет станицу, на которую нет хоть одной ссылки!
Так что вариант, когда файл отсутствует в нашей вселенной по очевидным причинам не рассматривается.
Именно по этому я не хочу хранить атрибуты.. Просто прямая ссылка на узел. 4..8 байт на 1 линк.
Есть другой вариант: хранить отдельным потоком файл с ключевыми словами. Места он займет больше. Поддерживать его, правда, проще..
У самого уже давно вошло в привычку давать описания файлам (благо файлМенеджеры типа DosNav и TotalCmd позволяют с ними нормально работать) Но вот если копируешь файл другой программой, или просто переименуешь - и трындец... Описание с файлом уже никак не связано..
Это, как раз основная причина, покоторой я хочу, чтобы целостность структуры поддерживала сама о.с.
Изменилось имя, местоположение файла, а ссылки остались.
В случае с отдельной системой нужен либо постоянный контроль целостности ссылок (переименовали файл, и где он теперь?), либо хранение данных в своей структуре, так, чтобы другие программы не имели к ним доступа
Особенно если еще и не в тему...
Похоже, это мой вопрос был не в тему.. :)
Но тема достаточно интересная.. Надо бы дать линки на в других форумах, мож народ выскажет ещё какие интересные мысли..
А что если воспользоваться "каким-нибудь стандартным языком разметки гипертекста" ? Тогда семантику ссылок можно будет прописать прямо в файле в человеко-читаемом виде...
Думал... Но опять же возникает проблема согласования ссылок: оригинальный файл прибили и..?
Но я не об этом. Я пока не понял идею системы. Поэтому нет смысла говорить о реализации (попробовать можно и на высоком уровне и даже с базами данных - главное разработать ЛОГИКУ системы (чтобы работала медленно и не надежно, но работала)). Использовать известную ФС (например как с длинными именами файлов) или проектировать что-то новое (более пригодное для данной задачи) - это все потом.
Вопрос насчет самой идеи:
В чем ее отличие от обычной древовидной структуры (насколько я понял... Вобщем хотелось бы услышать более четко - как должна выглядеть система (подробнее) и как ей пользоваться (не вдаваясь в тонкости реализации))?
Если просто заменить понятие файла и каталога комплексным понятием ФАЙЛ, а каталоги считать его частным случаем, то пока ничего не меняется. Остается та же структура. Корневой ФАЙЛ ссылается на другие и т.д.
Если нет верха и низа, а все файлы равноправны и могут быть связаны с любыми другими (именно с файлами, потому что понятие каталог не существует (он ведь тоже файл)), тогда возникает сеть, которая не имеет иерархии. То есть нельзя сказать кто кому принадлежит. Один файл ссылается на другой, тот - на другой, а тот - на первый! Если бы некоторые файлы могли не иметь ссылок, то как попасть с этих файлов на другие (я так понял, что переходы, поиск и вообще вся навигация идет по ссылкам)? В "равноправной" системе нет абсолютного адреса. Расположение файла определяется относительно ТЕКУЩЕГО файла. Путь формируется как последовательность ссылок. Минимум у файла должна быть одна ссылка - назад. Максимум - ко всем другим файлам. Кстати, обычная иерархическая структура - это частный случай данной системы. Хотелось бы подробнее узнать о ее новых возможностях.
Теперь о связях. Теоретически допускается возможность связать один файл хоть со ВСЕМИ остальными. Именно поэтому второй файл может иметь одну связь, третий - две, четвертый - три... А если файлов сотня?..
Насчет навигации. Если поиск файла идет по ссылкам, то надо иметь в виду, что путь тем длиннее, чем меньше ссылок (связей). Если файл связан со всеми, то путь к любому другому файлу - всего одна ссылка. Если файл связан только с одним другим файлом, то путь - вся череда переходов от файла к файлу по кольцу. Значит ссылок должно быть МНОГО. Могут быть (должны быть) ссылки назад, что бы перемещаться в двух направлениях по любому пути (это уже элемент дерева!).
Если я смотрю файл библиотеки, то меня может заинтересовать не только список авторов и список тем, но и список издательств и список еще чего-нибудь в этом роде. И уж во всяком случае интересует как из библиотеки выйти! Попасть в любимую игрушку, текстовый редактор и т.п. И желательно - сразу, побыстрей. То есть я не хочу перебирать пятьдесят ссылок (причем может быть совсем не очевидно даже как найти правильное направление), мне нужен короткий путь!!!
На этом хочу остановиться чтобы спросить: чем плохо дерево? В чем система отличается от него и что этим дает?
P.S.: Остановиться не получилось. Мысль прет...
Если отличие в том, чтобы иметь возможность перейти от одного файла к подобному (по некоторому признаку) файлу, или сгруппировать подобные файлы (сделать выборку), то иерархия не обязана пропадать!
Пусть остается привычная возможность навигации по каталогам (не важно как их называть).
А если надо воспользоваться дополнительными функциями, то это будет выглядеть как поиск или как выборка. Результатом будет список подобных файлов. Суть моей идеи - предоставить возможность перемещаться не только на файлы из этого списка, но и в другие места. Тут полезна иерархия. Всегда нужно иметь возможность взглянуть на информацию издалека, увидеть побольше, хотя и мелко.
Вобщем я понял так, что идея системы в банальных гиперлинках (если пока отвлечся от реализации).
Правильно ли я понял, или есть что-то еще?
P.P.S.: Действительно, зарядка!
PPPS: Кстати, и в самом деле, не обязательно хранить все признаки. Достаточно хранить в файле только ПРИСУЩИЕ ЕМУ атрибуты. Атрибут - это по сути и есть узел сети (он же - каталог).
Файл должен знать, каким каталогам он принадлежит а пользователь волен перейти в любой из них. Кажется в этом смысл системы (Я устал гадать...).
Или каталог знает, какие в нем файлы. Или файл - о своих каталогах.
О!!! Меня озарило... Нет каталогов! Точнее, каждый файл для связанных с ним файлов воспринимается ими как каталог.
Параллельные файлы (как например разные авторы (они ведь "равноправны")) просто не связаны между собой! Они все связаны со списков авторов. Каждый узел сети может быть атрибутом по которому делается выборка, и все файлы в выборке связаны напрямую с этим узлом.
Очевидное не всегда сразу доходит... Опять столько бумаги напортил в попытках ответить на свой вопрос...
PPPPS: См. P.P.S.
Лишний софт - это плохо. Общедоступные решения - это хорошо.
Но я не об этом. Я пока не понял идею системы. Поэтому нет смысла говорить о реализации (попробовать можно и на высоком уровне и даже с базами данных - главное разработать ЛОГИКУ системы (чтобы работала медленно и не надежно, но работала)). Использовать известную ФС (например как с длинными именами файлов) или проектировать что-то новое (более пригодное для данной задачи) - это все потом.
В том то и вопрос, что прежде чем пытаться реализовать идею её надо худо-бедно продумать... Что я и пытаюсь сделать.. :)
В чем ее отличие от обычной древовидной структуры (насколько я понял... Вобщем хотелось бы услышать более четко - как должна выглядеть система (подробнее) и как ей пользоваться (не вдаваясь в тонкости реализации))?
Если просто заменить понятие файла и каталога комплексным понятием ФАЙЛ, а каталоги считать его частным случаем, то пока ничего не меняется. Остается та же структура. Корневой ФАЙЛ ссылается на другие и т.д.
Если нет верха и низа, а все файлы равноправны и могут быть связаны с любыми другими (именно с файлами, потому что понятие каталог не существует (он ведь тоже файл)), тогда возникает сеть, которая не имеет иерархии.
Именно. Сеть, НЕ ИМЕЮЩАЯ ИЕРАРХИИ. Поэтому и пришлось отказаться от обычных ФС. Они отличаются в своей основе.
Это как раз одна из проблем. Как осуществлять сканирование такой структуры (допустим, для поиска...)?
Если бы некоторые файлы могли не иметь ссылок, то как попасть с этих файлов на другие (я так понял, что переходы, поиск и вообще вся навигация идет по ссылкам)?
Никак. Не предполагается, что все файлы будут связаны со всеми. Они будут просто группироваться по определённым критериям. Если файл является "родоначальником" темы, то у него может не быть ссылок вобще, или быть одна ссылка, допустим, на описание файла.
Не годится.. После блуждания по диску последовательность может быть недопустимо длинной (в пределе - занять всю память машины :)).
Нет, ссылок назад не предполагается.. Только вперед. Для возврата служит ограниченной длинны история. Или поиск заново, из корня.
Кстати, нодо будет, всё таки, продумать какой-нибудь механизм поиска определенного файла, когда не знаешь, как туда попал :)
..или когда надо узнать к каким группам файл относится.. БЛИН! :(
Надо что-то думать про ссылки "наверх"...
В пределе КАЖДЫЙ может быть связан с КАЖДЫМ! Вот только смысл? Именно по этому я и расчитываю, что структура хоть и будет существенно крупнее традиционной, но будет иметь, всё-таки приемлемые размеры..
Вопрос не том..
Как избежать повторного прохождения файла и зацикливания..
Ну, кто как, а я предпочитаю поиск вести из корня. При правильной организации непересекающиеся по смыслу файлы без проблем укладываются в неглубокое дерево.
Вернёмся к началу...
Эта ФС предполагает хранение не программ, а именно документов, пересекающихся по смыслу в разных плоскостях. Причём документов разного рода: текстов, чертежей, картинок, фотографий.. да и мало-ли чего ещё?
Если отличие в том, чтобы иметь возможность перейти от одного файла к подобному (по некоторому признаку) файлу, или сгруппировать подобные файлы (сделать выборку), то иерархия не обязана пропадать!
Так ведь я не отрицаю иерархии! Ещё раз повторяю. Дерево я вляется частным случаем планируемой системы и во многих случаях система и будет работать только на этом уровне (замена каталога файлом существенной роли тут не играет). Пересечения будут создаваться только по мере необходимости.
А если надо воспользоваться дополнительными функциями, то это будет выглядеть как поиск или как выборка. Результатом будет список подобных файлов. Суть моей идеи - предоставить возможность перемещаться не только на файлы из этого списка, но и в другие места. Тут полезна иерархия. Всегда нужно иметь возможность взглянуть на информацию издалека, увидеть побольше, хотя и мелко.
Вобщем я понял так, что идея системы в банальных гиперлинках (если пока отвлечся от реализации).
Правильно ли я понял, или есть что-то еще?
Типа того.. Но информация в виде сети (на мой взгляд) более наглядна (хотя, и сложнее визуально)
А то! :)
Файл должен знать, каким каталогам он принадлежит а пользователь волен перейти в любой из них. Кажется в этом смысл системы (Я устал гадать...).
Или каталог знает, какие в нем файлы. Или файл - о своих каталогах.
По моей идее - каталог знает о файлах, но файлы не знают о каталогах.
В связи с проблемой определения групп, вероятно, идею надо будет пересмотреть..
Параллельные файлы (как например разные авторы (они ведь "равноправны")) просто не связаны между собой! Они все связаны со списков авторов. Каждый узел сети может быть атрибутом по которому делается выборка, и все файлы в выборке связаны напрямую с этим узлом.
Именно. :)
Зато подал несколько идей :)
Мысли никогда не пропадают впустую.
У меня появилось такое представление. Не знаю насколько оно совпадает с тем что имелось в виду.
Имеется жесткий диск. На нем секторы. Секторы объединены в кластеры.
Имеется таблица расположения файлов FAT. В каждой ячейке FAT лежит информация: кластер свободен / занят файлом (начало/продолжение/конец) / кластер непригоден.
Вся остальная информация файловой системы представлена самим файлом.
В файле хранится напосредственно информация (может и отсутствовать), имя и описание файла, всякие атрибуты типа ReadOnly и т.п., и наконец специфиная для данной системы служебная область.
В этой области хранятся ссылки на другие файлы. Ссылка - это просто номер кластера, в котором находится начало файла.
Область эта - переменной длины. Каждый элемент (ссылка) занимает 4 байта (сколько надо под номер кластера).
Смысл этих ссылок такой. Если файл "А" ссылается на другой файл "Б", это значит, что файл "Б" может трактоваться как подкаталог для файла "А".
Ссылки взаимны. Это значит, что если на файл есть ссылка, то и в этом файле имеется ссылка на тот файл.
Новый файл создается в привязке к уже существующему (для пользователя это выглядит как создание файла в каталоге). Появляется что-то вроде виртуального каталога. Любой файл можно считать каталогом, а все связанные с ним файлы - его подкаталогами. При этом сам файл является одним из подкаталогов для каждого связанного с ним файла.
Таким образом новый файл получает сразу одну ссылку - на тот файл, который в момент создания трактовался как текущий каталог.
При переходе на связанный файл, таковой становится текущим каталогом. В нем имеются подкаталоги - все связанные с ним файлы.
Когда пользователь заходит в подкаталог, он становится текущим. При этом он содержит все связанные с ним файлы (они же - подкаталоги), в том числе и тот файл (т.е. каталог, что - одно и то же) с которого был совершен переход в текущий.
Ссылку на другой файл можно добавить или удалить в любое время. При этом ссылка добавляется или удаляется в обоих файлах.
Так как в файле есть ссылки на все связанные с ним файлы, то при его удалении не представляется сложным найти эти файлы м удалить из них ссылку на удаляемый файл. Таким образом целостность системы поддерживать легко.
Файлы могут быт вырождеными. Это либо когда файл содержит только ссылки (аналог обычного каталога), либо когда файл содержит информацию и только одну ссылку. В этом случае получается структура привычная еще со времен DOS.
Пример использования.
Имеется файл "библиотека". Он не содержит собственной информации. Он связан с файлами "авторы", "книги".
Файл "авторы" для простоты не имеет своей информации. Он связан с файлами "Иванов", "Петров", "Сидоров".
Файл "книги" тоже пустой. Он связан с файлами "Книга 1", "Книга 2", "Книга 3", "Книга 4".
Файл "Иванов" содержит биографию автора (Иванова, разумеется). Он связан с файлом "Книга 1". И с файлом "авторы".
Файлы "Петров" и "Сидоров" аналогичные. Петров автор книги 2 и 3. Сидоров автор книги 3 и 4.
У книги 3 получается два автора.
Так вот...
Захожу я в файл "библиотека" (для простоты считаем, что это вроде корневого каталога (в него мы попадает сразу после старта системы)).
Вижу список: авторы, книги. Содержания нет.
Захожу в книги.
Вижу список: книга 1, книга 2, книга 3, книга 4, библиотека.
Захожу в "книга 1".
Вижу саму книгу (сейчас не важно в каком виде - например отдельно вынесенный файл к которому можно применить программу просмотра, редактирования и т.п. (например исполняемый файл можно запустить)). Вижу список: Иванов, книги.
Захожу в "Иванов".
Вижу отдельно файл про Иванова а также список: книга 1, авторы.
Захожу в "Авторы".
Отдельного файла нет, но есть список: Иванов, Петров, Сидоров, библиотека.
Захожу в "Петров".
Вижу файл про Петрова, а также список: книга 2, книга 3, авторы.
Захожу в "Книга 3".
Вижу файл книги, а также список: Петров, Сидоров, книги.
И т.д.
Логика понятная. Но реализация у меня лично большого энтузиазма не вызывает. Хотя алгоритм понятен.
Я не знаю как это можно встроить в какую-то известную операционную систему. Хотя думаю, что это возможно.
Новую систему тоже так сразу не создашь.
Вобщем идея интересная, но сама по себе в отдельности ничего не дает.
Если кто-то хочет всерьез заняться ее реализацией (и что-то умеет) - тогда другое дело. А может кто-то желает довести идею до чего-то более интересного (самодостаточного)...
Тут есть еще вопросы:
Что значит копирование в этой системе?
Как быть с уникальностью имен файлов (ведь два файла с одинаковыми именами могут когда-нибудь оказаться в одном каталоге (это как раз продолжение вопроса о копировании))?
Может стоит в FAT ввести бит указывающий, что данный кластер содержит начало файла (для поиска файлов, исключающего возможность бегать по ссылкам по кругу)?
P.S.: Список файлов в каталоге может быть получен из ссылок. Так как ссылка - это номер кластера, то достаточно в этот кластер заглянуть и в соответствующем поле прочитать имя файла, описание и т.п.
У меня появилось такое представление....
В целом верно, за исключение того, что за основу я предполагаю брать ext2. На сколько я разобрался в ней по найденным обрезкам описаний - там уже частично есть необходимые механизмы..
Новую систему тоже так сразу не создашь.
Вобщем идея интересная, но сама по себе в отдельности ничего не дает.
Если кто-то хочет всерьез заняться ее реализацией (и что-то умеет) - тогда другое дело. А может кто-то желает довести идею до чего-то более интересного (самодостаточного)...
Я придерживаюсь менения, что возможно всё. Вопрос в ресурсах :)
Что значит копирование в этой системе?
Как быть с уникальностью имен файлов (ведь два файла с одинаковыми именами могут когда-нибудь оказаться в одном каталоге (это как раз продолжение вопроса о копировании))?
Об этом я не подумал.. :( Придётся доработать!:)
Возможно, надо добавить возможность сохранять файл под разными именами. В конце концов важно его содержимое...
А вот с копированием - сложно по другой причине..
Как копировать СОДЕРЖИМОЕ КАТАЛОГА? Как определить, где кончается каталог?
Можно, конечно, копировать только те файлы, которые не имеют внешних (т.е. ведущих за пределы каталога) ссылок.. Но вот как это контролировать???
Не совсем понятно, что это даст? Да и исключить возможность бегать по кругу не удается пока никак. Все ссылки предполагаются РАВНОЗНАЧНЫМИ, т.е. это именно файл, присутствующий в каждом каталоге, а не один экземпляр файла и куча ссылок.
Тут как раз никаких вопросов не возникает..