>>4603985
Так одно от другого очень даже зависит же! Чтобы теги и каталоги могли быть одной и той же сущностью на уровне файловой системы. Вот есть сейчас возможность записывать теги в xattrs файла... а много ли пользы в этом, если нужно наоборот? Ну, почти наоборот. А сейчас с этими тегами удобно иметь дело только из одной специфической системы тегов, одного файлового менеджера и одной программы просмотра картинок, которые собраны с одной специфической библиотекой абстракции над разными локальными и не очень источниками. Baloo, Dolphin, Gwenview и KIO. И то, возможности выборок по произвольным сочетаниям очень не хватает...
>>4603989
«Декаплинг» — это в смысле от decouple? Как бы то ни было, не помешает и в самом деле рассмотреть какой-нибудь простейший пример.
Ну вот допустим, у нас есть картинка с Сырно (←). Мы хотим положить её в несколько каталогов (или в несколько тегов) — например, «/Touhou/Сырно», «Ычан», «hoodie», «⑨», «dual_persona», «wings:no», «triangles:no» и «Бака это ты» особый, специальный тег для картинок с такой надписью. Допустим, мы делаем это при помощи механизма жёстких ссылок. И это значит, что теперь у нас есть одна и та же inode, на которую ссылаются несколько файлов, на которые, в свою очередь, ссылаются несколько тегов-каталогов. Дополнительного места она благодаря всему этому не занимает. Пока что всё хорошо. Ну, почти.
Но что если теперь мы захотим как-то отредактировать эту картинку? Ну там, разрезать, изменить размер, добавить надпись... Для ясности предположим, что мы хотим отрезать левую Сырно. И при этом:
- в явном виде сохранить связь между первоначальной и отредактированной версией;
- применить изменения только к нескольким копиям этой картинки. Или вообще только к одной.
Сейчас произойдёт так, что безвозвратно изменятся все её копии, лежащие в каждом из этих тегов-каталогов. Тогда как хотелось бы сохранить как минимум для некоторых из них возможность возвращения к первоначальному виду. И вообще, после разрезания она перестанет соответствовать как минимум двум из этих тегов. Или не изменится ни одна из них — если мы сохраним изменённую картинку в новый файл. Но тогда потеряется и связь между ними, которую хотелось бы отслеживать!
В общем, как-то не очень.
А теперь предположим, что именованные записи могут ссылаться на произвольное число блоков данных, и что номера инодов заменены хэшами блоков данных. И что мы открыли в редакторе картинку из тега «Ычан». Тогда:
- при сохранении из редактора ОС допишет к исходной именованной записи [=(мета)файлу] хэш нового блока данных, который будет содержать картинку с той Сырно, что слева;
- сделает этот новый хэш основным для того метафайла, который будет лежать в теге «
Ычан»;
- и может быть, автоматически добавит этот же хэш ко всем остальным метафайлам, которые на момент создания представляют из себя точную копию отредактированного, но делать его основным для них не будет. HEAD сместится только для метафайла, лежащего в теге-каталоге «Ычан».
При этом мы:
- Сможем создать сколько угодно новых метафайлов, содержащий ссылку на единственный хэш нового блока с отрезанной левой Сырно, если мы того захотим — нового места при этом занято не будет;
- Сможем перемещаться по истории отредактированного файла в любую сторону, удаляя из каждого тега-каталога не понравившиеся или более не нужные экземпляры.
Намного лучше, не так ли?
(Это оно, или я случайно не в ту сторону?)
>>4604037
В общем, тут начинаются детали реализации, о которых хорошо бы подумать отдельно и обстоятельно и с рисуночками и всем таким прочим. Такое ощущение, что эти вот детали без знания NTFS-специфики осмыслить получается... ну, не очень.
Вот что такое «потоки», например? Чувствуется, что это какой-то специфический NTFS-термин. А в понимании специфических терминов лучше бы не полагаться на один только common sense.
>>4604042
Вот, в этом и суть! В ядре и в ФС многие или даже все возможности уже есть, и даже CoW-FS уже есть, и их возможности даже в некоторых специфических местах уже очень активно используются, но вот без переделывания прикладных инструментов действовать в качестве структуры тегов оно не будет. И вот для плавного перехода и могло бы пригодиться следствие 3 явное разделение на стандартный системный индекс именованных записей, который изображал бы стандартное дерево ФС для всех уже написанных прикладных инструментов, и на дополнительные системные индексы, создаваемые пользователем. С ними могли бы постепенно учиться работать сначала некоторые программы, затем ещё некоторые...
