Комментарии 44
Есть одно но. Допустим на диске 100 000 мелких файлов. 10 из них находятся в одной папке с уровнем вложенности 7. Каким образом, при открытии папки в проводнике, их быстро найти?)
посмотри в википедии: inode. Т.е. "внутри" оно уже давным давно именно так и представлено.
А теперь ответь вот на какой вопрос: есть программа "x" для которой требуется наличие некоего файла в системе. Каким образом программист должен указать путь (или индекс, или еще что-то...), по которому программе предстоит искать данный файл?
А теперь ответь вот на какой вопрос: есть программа "x" для которой требуется наличие некоего файла в системе. Каким образом программист должен указать путь (или индекс, или еще что-то...), по которому программе предстоит искать данный файл?
Хм, конечно же да, все это любопытно. Ну а что если тогда сделать так, что системные файлы носят одинаковые имена-коды везде. Т.е. программист знает не название файлов, не путь, а знает имена-коды…
и в чем тогда будет принципиальная разница от современных ОС?
Системные файлы еще как-то можно привести к такому виду. Но вот я, допустим, создаю программу и хочу, чтобы у каждого пользователя был свой конфигурационный файл (ну и еще один, с основными параметрами, для всех пользователей). Случай с пользователями еще как-то решаем путем создания данного файла при первом запуске. Но как быть, если я захочу создать конфиг заранее и раскидать его всем пользователям. С вашим подходом, мы либо теряем в гибкости, либо теряем в простоте использования, перегружая пользователя ненужными задачами по организации файлового пространства. Это примерно то же самое, как если бы вам было разрешено самостоятельно размещать комнаты в ваших квартире или личном доме... получилось бы как в рассказе про то, что было бы, если задание по постройке дома дали группе программистов.
В каком случае проще найти страницу 472 в книге "Облако":
а) если книга находится где-то в зале под номером 5, площадью 1000кв.м, заваленном книгами;
б) если книга находится в зале, разбитом на комнаты, а в каждой комнате шкафы с пронумерованными полками;
Очевидно, что второй вариант лучше.
а) если книга находится где-то в зале под номером 5, площадью 1000кв.м, заваленном книгами;
б) если книга находится в зале, разбитом на комнаты, а в каждой комнате шкафы с пронумерованными полками;
Очевидно, что второй вариант лучше.
ты, наверное, хотел сказать что интрузивная огранизация контента - это отстой, а неинтрузивная - круто?
например, дуализм "папки vs. метаданные (теги)"
теги/метаданные - это правильная идея, т.к. это отделяет контент от структур, его организующих (принцип separation of concerns, conquer and divide), позволяет более гибко манипулировать контентом и его представлением по отдельности по сравнению с жесткой иерархией
лучше подумай о том, как расширить концепт тегов чтобы не потерять удобство и семантику папок (вложенность, например)
подумай о том, как сделать удобную навигацию и поиск
организация контента (и в вебе и на HDD пользователя) - это очень актуальная тема сегодня
например, дуализм "папки vs. метаданные (теги)"
теги/метаданные - это правильная идея, т.к. это отделяет контент от структур, его организующих (принцип separation of concerns, conquer and divide), позволяет более гибко манипулировать контентом и его представлением по отдельности по сравнению с жесткой иерархией
лучше подумай о том, как расширить концепт тегов чтобы не потерять удобство и семантику папок (вложенность, например)
подумай о том, как сделать удобную навигацию и поиск
организация контента (и в вебе и на HDD пользователя) - это очень актуальная тема сегодня
погугли "WinFS", посмотри видео с msdn tv
в Windows 7 обещают таки зарелизить
в Windows 7 обещают таки зарелизить
А по-моему идея занятная :) То есть, как я понял, все файлы лежат по папкам как обычно, но доступ к ним идет по уникальному идентификатору.
для аналогии - посмотри на хабратопик в котором ты сейчас находишься
он находится в каталоге под названием "персональный блог пользователя anthropomorphic"
но вместе с этим помечен тегами "файловая система", "операционная система", "идея"
по сути, какие различия между каталогом и тегом? подумай
он находится в каталоге под названием "персональный блог пользователя anthropomorphic"
но вместе с этим помечен тегами "файловая система", "операционная система", "идея"
по сути, какие различия между каталогом и тегом? подумай
Совершенно верно, суть как раз в этом. Конечно вопрос реализации не продуман до конца, но идея собственно такая.
Ретро! Те кто тут говорят про WinFS явно не слышали про BeFS. Причем в отличии от WinFS она реально работала :)
http://ru.wikipedia.org/wiki/BeFS
http://ru.wikipedia.org/wiki/BeFS
Файловая система ext3 представляется мне весьма неплохой - среднему юзеру, вместо того, чтобы искать нужный файл по всему разделу, ищет его у себя в домашней папке.
Но в ext3 неплохо было бы расширить inode, чтобы туда влезли acl наподобие виндовых, ну и дополнить его полем метаданных, ибо удобная штука.
Но в ext3 неплохо было бы расширить inode, чтобы туда влезли acl наподобие виндовых, ну и дополнить его полем метаданных, ибо удобная штука.
Эх. Вы просто не видели Plan9.
Что-то не припомню в файловой системе Plan9 чего-то такого.
Ну как. А индивидуальные для каждого процесса namespace'ы - это разве не то же самое? Конечно, это немного в ограниченном виде, но всё же, весьма похоже, imho.
Совсем не тоже самое. В случае BeFS можно каждому файлу назначать метаданные и искать по ним.
Кажется, в начальном посте говорится только про имена. Ну да ладно. Не важно... Но вообще возникает вопрос: а зачем метаданные вносить в структуру файловой системы? Место лишнее тратить? Вряд ли пользователю захочется индексировать системные библиотеки, например. Всё же теги лучше хранить как-то в системе индексирования по тегам. В специальном, заточенном под поиск формате, в префиксном дереве каком-нибудь. Как-то так вот.
И ещё такая мысль: если тэги можно упорядочить по возрастанию объёма (или важности) данных, помечаемых ими (а такое ощущение, что это почти всегда можно сделать), то директории вполне будут этим тэгам эквивалентны. Нет?
Хм. И вообще. Я слабо представляю себе работу с тэгами на уровне файлов. Вот есть у меня около тысячи музыкальных файлов. Это я должен на каждый кликнуть, чтобы приписать ему метки? IMHO, перетащить в директорию намного проще: 1. она уже существует и путь к ней уже отражает суть произведений, хранящихся в ней, и мне не нужно выдумывать новые слова и боятся забыть то слово, которым я помечал похожие произведения; и 2. для перетаскивания в директорию (хоть из коммандной строки, хоть из gui) нужно совершать меньше телодвижений.
И ещё такая мысль: если тэги можно упорядочить по возрастанию объёма (или важности) данных, помечаемых ими (а такое ощущение, что это почти всегда можно сделать), то директории вполне будут этим тэгам эквивалентны. Нет?
Хм. И вообще. Я слабо представляю себе работу с тэгами на уровне файлов. Вот есть у меня около тысячи музыкальных файлов. Это я должен на каждый кликнуть, чтобы приписать ему метки? IMHO, перетащить в директорию намного проще: 1. она уже существует и путь к ней уже отражает суть произведений, хранящихся в ней, и мне не нужно выдумывать новые слова и боятся забыть то слово, которым я помечал похожие произведения; и 2. для перетаскивания в директорию (хоть из коммандной строки, хоть из gui) нужно совершать меньше телодвижений.
Но вообще возникает вопрос: а зачем метаданные вносить в структуру файловой системы? Место лишнее тратить?
Много места они занимать не будут. В случае реализации аля NTFS (потоками), так вообще без проблем.
Вряд ли пользователю захочется индексировать системные библиотеки, например.
Нет метаданных нет индекса.
Хм. И вообще. Я слабо представляю себе работу с тэгами на уровне файлов. Вот есть у меня около тысячи музыкальных файлов. Это я должен на каждый кликнуть, чтобы приписать ему метки?
А что автоматизировать при наличии API очень сложная задача? :)
IMHO, перетащить в директорию намного проще:
В случае перемещения файла и наличия метатега у него можно будет более правильно и что самое главное автоматически произвести сортировку и построить иерархию. К примеру тот же амарок работает с музыкой и ее метаданными, а не с файлами и каталогами. Как результат файлы можно двигать куда угодно и как угодно. Сортировать коллекцию можно как угодно.
Хотя, конечно, метки они могут быть весьма полезными. Возможность хранить файл в нескольких разных множествах может быть привлекательной. Но с другой стороны, это всё же реализуется директориями. Например. Есть у нас google и intel. Есть google/techdoc, есть intel/techdoc. И всегда можно написть find -name '*/techdoc'. Правда, с метками могло бы быть эффективнее. Вобщем, тут думать надо
АААА! Папки!
Папок в ФС не бывает, это фантастика! Есть только каталоги!
Папок в ФС не бывает, это фантастика! Есть только каталоги!
Поднял карму. ИМХО если человек сам дошел до такой мысли - молодец.
Т.е. самое важное — это имя-код - ага, это и есть полное имя файла =)))
Так что все что вы описали и есть в операционной системе, у каждого файла есть уникальное имя-код - это полный путь до файла. И во всех системах он одинаковый =)
Так что все что вы описали и есть в операционной системе, у каждого файла есть уникальное имя-код - это полный путь до файла. И во всех системах он одинаковый =)
Вообще, насколько я помню, все ждали от висты какой-то чудо-файловой системы реляционного типа или что-то в этом роде, чуть ли не с поддержкой SQL...
Если я правильно понял, вы предлагаете оставить, иерархию каталогов только, для пользователей... но она и была создана только для них и не для кого больше, на дисковом пространстве все файлы хранятся в одной куче, как вы и предлагаете, просто привязаны идентификатором к определенному каталогу.
и я думаю не стоит рассказывать что такое фрагментация файлов %) удачи вам ваших начинаниях, эта идея кокой бы она бы не была старой, хороша.
и я думаю не стоит рассказывать что такое фрагментация файлов %) удачи вам ваших начинаниях, эта идея кокой бы она бы не была старой, хороша.
уже есть фс, где к каждому фаилу можно добавить теги. ваша фс - лишь частный случай таких. не вижу ничего нового и гениального :)
Идея не нова, что-то подобное реализовывалось в WinFS, как писали выше. В любом случае. Мысль есть, а это хорошо.
Но есть такой момент.
Допустим, на нашем компьютере все отлично, программы ищут файлы по внутренним идентификаторам aka id auto_increment, допустим. Мы можем их перемещать по мнимому (для ОС) дереву каталогов. Все будет отлично работать.
Но если мы попытаемся перенести файл на другой компьютер? Как мы будем сохранять идентификатор файла? Как мы добьемся его уникальности на обоих машинах без повторной генерации?
Но есть такой момент.
Допустим, на нашем компьютере все отлично, программы ищут файлы по внутренним идентификаторам aka id auto_increment, допустим. Мы можем их перемещать по мнимому (для ОС) дереву каталогов. Все будет отлично работать.
Но если мы попытаемся перенести файл на другой компьютер? Как мы будем сохранять идентификатор файла? Как мы добьемся его уникальности на обоих машинах без повторной генерации?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Идея файловой системы