> Те самые потоки (metadata) наконец-то начиинают активно использоваться на уровне файловой системы

все-таки потоки и метаданные - разные вещи. ;) первое может (а может, и не) использоваться для хранения второго.

Так оно и сейчас используется. Вот ACL на NTFS в отдельных потоках храниться. Вот только почему-то иконки и описание представленияы каталогов они никак не могут туда запихать. Но мне кажется, тут все дело в том, что команда Windows Explorer и команда NTFS никогда не встречались.

Знаете, что это мне напомнило? Кобол. Те же самые идеи "возможности построения запроса на человеческом языке". История развивается по спирали, однако. На ошибках прошлого красноглазые сумасшедшие не учатся.

>еденицей

:(

hmmm

a pocemu ne mogut riadom (parrallelno) sushestovaat' i prostaja failovaja sistema - sql-analogija?

sistemshsikam/programeram - failovuju uzzveriam - sql-analogiju

a vot kohda hard disk poletit - vot tohda i budet vam SQL!!! cerez odno mesto ;)

ibo, cem prozrachnee sistema i proshe v architekture - shans na vostanovlenie dannyx uvelicivaetsia v progresse ;)

(interesno ktoto tut s kakim "diskedit"om vostanavlival ntfs ili reiserfs posle smerti.... eto vam ne fat16/fat32 :)

так вот почему все говорят что в прибалтийских странах так чисто. it отрасль жалко только. хотя зачем она им если на шпротах жить можно

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

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

nado esio v "failovuju sistemu" mnogourovnevyj UNDO sdelat' mehaniz'm

tohda vashe zashibis' budet, NADIOZHNOST' vozrastet v N raz

a rezervnyje kopii (eto naciot winfs) pust' po inetu sliotsia na sait M$, im ne privykat', zato kakaja zashita dannyx:)

odnim slovom bred bredom

RABOTAT' IDITE! =]

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

http://www.apple.com/macosx/tiger/spotlight.html

прикольно сделано в беосе.

создаешь аттрибуты для файла
и благодаря запросам (queries)
директории становятся теперь логическим уровнем
представления.

так что не нужны никакие симлинки.

Файловые системы с DB (не знаю, как в этой, читать лениво, но аналогичные WinFS и ZopeDB) предназначены не для отмены файлов и папок, а для расширения понятия файла до понятия "объект". У каждого файла кроме контента должны быть атрибуты. Это могут быть примитивные атрибуты ОС - R/O, exec и т.п. Это могут быть расширенные атрибуты, введённые в формат - ID-тэги, EXIF и т.п. второе - это костыли, которыми пытаются поправить убогость нынешних FS.

DB в файловой системе позволяет вводить произвольные новые атрибуты любым типам объектов (каталогам, файлам и т.п.), т.о. позволяя штатно отказаться от таких костылей.

Вот нужно мне, скажем, для Plain/text-файлов хистори общения указывать, например, имена "от кого" и "кому". Сейчас - надо изобретать свой формат. В DBFS - можно будет просто ввести два поля для нового типа, наследуемого от базового.

А про то, что DB - "тормоза" - это говорят люди, не работавшие реально с контентом на нормальных БД. Сколько будет занимать сканирование хотя бы по именам каталога с 1 млн файлов? А в проавильно спроектированной ДБ - от долей секунд до секунд. Нынешние FS совершенно не занимаются никакой индексацией и т.п...

Кстати, с нормальной DBFS можно будет, наконец, отказаться от идиотской древовидной структуры каталогов перейдя, наконец, к естественной из направленных графов. Т.е. когда у каталога, скажем, может быть больше одного родителя. "Авианосец" может позиционироваться и в разделе "Море" и в разделе "Авиация". В нынешних FS это невозможно. В новых DBFS - достаточно будет к полям типа "Childs" добавить поля "Parents".

>Кстати, с нормальной DBFS можно будет, наконец, отказаться от идиотской древовидной структуры каталогов перейдя, наконец, к естественной из направленных графов. Т.е. когда у каталога, скажем, может быть больше одного родителя. "Авианосец" может позиционироваться и в разделе "Море" и в разделе "Авиация". В нынешних FS это невозможно. В новых DBFS - достаточно будет к полям типа "Childs" добавить поля "Parents".

Respect. Читать всем.

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

В UNIX это называется "Hard Links".

Вдогонку, тем, кто не любит теорию, а предпочитает практику.

Вот прямо мой текущйи пример на экранеь. Берём iTunes (раз не любим MS). У него, на ряду с прочим, есть такая приятная фича, как играть MP3, в которых в ключевых тэгах есть фрагмент, вбитый в строке поиска в шапке проигрывателя. Т.е. прямо во время игры вписываем там "beat" в поле ввода, остаётся список песен Beatles (ну, возможно, ещё что-то попадёт, если больше писать лень). Чтобы всё это работало быстро и без тормозов, iTunes предварительно сканирует все каталоги с целью сбора информации о всех MP3 в единую медиатеку. Которую хранит внутри себя в БД. А если этой БД будет сразу файловая система? Удобно и программистам и пользователям (одна "база" может в разных программах работать. А, например, картинки - обложки альбомов можно будет линковать прямо в параметры песни)

Второй пример - ближе сообществу Linux'оидов (iTunes, кажется, только под OSX и Win32 есть). Делаю я CMS для своего сайта. Именно на нормальной графовой системе. Основные атрибуты объектов хранятся в БД. Скажем, чтобы ширина и высота картинки были в БД, и не требовалось для их вычисления файл открывать. Или чтобы описание файла шло не где-то там, а прямо в его параметрах. Да, отчасти велосипед изобретаю, тот же Zope-DB есть, но мне Python и Zope не подходят. Была бы на сервере DBFS - я бы не потратил на разработку такой системы с нуля около полугода (хоть и ненапряжной) работы. А просто воспользовался бы возможностями OS. Но пока - такого нет.

Ждём-с... :) (и лепим на время ожидания свои костыли)

>В UNIX это называется "Hard Links".

Хардлинк тебе скажет, кто является "родителем" у "Авианосца"? пойдя по двоеточию ты придёшь только либо к "Морю", либо к "Авиации". Но не к одному из них на твой выбор.

Хардлинки и симлинки всё равно оставляют только одного родителя.

Тем более, что они - всё равно костыли при рассмотрении с точки зрения DBFS :) (не конкретно сабжевого продукта, а как класса систем)

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

> В UNIX это называется "Hard Links".

# ln /tmp /tmp/11
ln: `/tmp': не разрешено создавать жесткую ссылку на каталог

> Вот нужно мне, скажем, для Plain/text-файлов хистори общения указывать, например, имена "от кого" и "кому". Сейчас - надо изобретать свой формат. В DBFS - можно будет просто ввести два поля для нового типа, наследуемого от базового.

Иными словами, Вы хотите сказать, что если пользователь не в состоянии осмыслить понятия каталог/файл, то он будет в состоянии понять OO-модель с наследованиями/перегрузками и всем прочим, заодно пропатчив и пересобрав всё по для осмысленного реагирования на привнесённые им атрибуты???

Ага. Замечательно! Заменим ID3 и ему подобные потоками ФС! Всё хорошо... Только вот как файлы копировать? Как мне один и тот же файл принести на дискете (сорри, на CD - кстати, а как к этому отнесётся ISO9660?) к другу с BSD на RaiserFS (если он есть в BSD), к родителям Linux на ext3, к боссу с XP (ну хорошо, с лонгхером)?

> А про то, что DB - "тормоза" - это говорят люди, не работавшие реально с контентом на нормальных БД. Сколько будет занимать сканирование хотя бы по именам каталога с 1 млн файлов? А в проавильно спроектированной ДБ - от долей секунд до секунд. Нынешние FS совершенно не занимаются никакой индексацией и т.п...

Вы в "правильно спроектированной ДБ" все данные сваливаете в одну таблицу? Что-то мне подсказывает, что нет. Так почемы вы считаете, что свалка всех файлов в один каталог это хорошо и правильно? (Последнее -- это единственный вариант, при котором я могу понять, откуда у вас 1e6 файлов в каталоге взялось)

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

Опять-таки, если пользователь не в состоянии понять, что такое дерево, то он тем более не сможет понять более общие случаи. Для него навигация станет блуждание в лабиринте. И вот тогда-то и случиться помойка с 1e6 файлов в одном каталоге (или как Вы там назовёте эту сущность).

>Только вот как файлы копировать?

А как копируютсся сейчас файлы с метаданным NTFS на ext3?
Или файловыми атрибутами MacOS на на FAT12?
Или всей атрибутикой Linux на BeOS?

Совместимости по атрибутам между нынешними FS нет. В будущем, если не договорятся о стандарте, будет просто ещё хуже.

На самом деле - это просто решается вопросом экспорта/импорта в тот же XML или иные структуры данных.

Понятно, что все данные с DBFS на простую FS без потерь не перенесёшь. Но и от структуры каталогов никто не отказывается из-за того, что, например, CP/M или DOS 3.0 её не понимает.

>Вы в "правильно спроектированной ДБ" все данные сваливаете в одну таблицу? Что-то мне подсказывает, что нет. Так почемы вы считаете, что свалка всех файлов в один каталог это хорошо и правильно?

Это просто речь о скорости выборки. Хорошо, пусть будет не миллион файлов, а 100, но при 1000 чтениях и желательно, при этом без тормозов. Для БД - плёвое дело. Для FS - уже напряжно. И это ещё без учёта расширенных атрибутов. Ну-ка, найди мне средствами одной FS все песни 2001-го года из 4000 песен, хранящихся на диске? В DBFS - дело одного запроса.

>Опять-таки, если пользователь не в состоянии понять, что такое дерево, то он тем более не сможет понять более общие случаи.

См. выше пример с тем же iTunes. Там пользователю вообще не нужно знать никаких каталогов.

>сорри, на CD - кстати, а как к этому отнесётся ISO9660?

А как FAT12 на дискеттке отнесётся к имени "latex2html-pngicons-2002.2.1-358.noarch.rpm"?

Все эти WinFS мертворожденные потому что данные имеют различную природу и следовательно для их поиска нужно применять различные алгоритмы. Короче конь в вакууме. Мертворожденный.

>Все эти WinFS мертворожденные потому что данные имеют различную природу и следовательно для их поиска нужно применять различные алгоритмы.

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

> А как копируютсся сейчас файлы с метаданным NTFS на ext3?
> Или файловыми атрибутами MacOS на на FAT12?
> Или всей атрибутикой Linux на BeOS?

До абсурда не доводим, хорошо? В нынешних FS всё содержмсое файла (ID3, к примеру) находится В САМОМ ФАЙЛЕ и при копировании не теряется. Кому какое дело, что потерялся атрибут hidden или readonly?? Это легкл восстановимо при необходимости. А вот как ты будешь потерянный ID3 восстанавливать - не подскажешь?

> А как FAT12 на дискеттке отнесётся к имени
> "latex2html-pngicons-2002.2.1-358.noarch.rpm"?

А ты, милок, никогда не копировал длинные имена на дискеты? Попробуй и удивись. Потом смонтируй её в линуксе и удивись ещё больше. Что, никогда не делал? А зачем тогда глупости говоришь?

>А ты, милок, никогда не копировал длинные имена на дискеты? Попробуй и удивись. Потом смонтируй её в линуксе и удивись ещё больше. Что, никогда не делал? А зачем тогда глупости говоришь?

Вот и для новых FS сделают расширения имеющихся. Или ты будешь утверждать, что FAT12 понимает длинные имена? :D

> Вот и для новых FS сделают расширения имеющихся.

Шо, таки для всех? И где этот Геракл, явите мне его! Сколько сейчас FS существует и активно используется? А M$ в этом заинтересована? Если ей за это явно платить не будут? Как я понял, всё просто сводится к очередной попытке настричь бабла с лохов на великие цели?

> Или ты будешь утверждать, что FAT12 понимает длинные имена? :D

Нет, на то есть VFAT

>> Опять-таки, если пользователь не в состоянии понять, что такое дерево, то он тем более не сможет понять более общие случаи.

> См. выше пример с тем же iTunes. Там пользователю вообще не нужно знать никаких каталогов.

Ответ #1: а где же тогда файлы лежат? Кто-то же их куда-то положил! Или всё-таки свалка по принципу "всё гамузов в одном месте"? Но тогда причём тут графы или их "деревянные" подмножества?

Ответ #2: OK. Пример про iTunes. Пользователь получит какие-нибудь преймущества при переходе с <что-там-на-MacOS> на DBFS? По моему, проще ему не станет. Разработчикам iTunes -- тоже. Ибо они не смогут сказать "работаем только на такой-то FS", поскольку не самоубийцы. Т.е. им просто прийдётся писать ещё одну дополнительную ветвь, уменьшая там самым надёжность. Значит писать её не станут. Значит для iTunes DBFS просто бесполезна. (Конечно, вместо DBFS можно подствить любое другое имя.)

>> Или ты будешь утверждать, что FAT12 понимает длинные имена? :D

> Нет, на то есть VFAT

...Которая есть костылем и для FAT12, и для FAT16, JFYI.

>> Взять с полки (винта) одну папку и открыть ее, где в красивых пластиковых прозрачных файлах будут храниться документы.

>А куда делись папки, которые я брал с полки до этого?

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

>>Кстати, с нормальной DBFS можно будет, наконец, отказаться от идиотской древовидной структуры каталогов перейдя, наконец, к естественной из направленных графов. Т.е. когда у каталога, скажем, может быть больше одного родителя. "Авианосец" может позиционироваться и в разделе "Море" и в разделе "Авиация". В нынешних FS это невозможно. В новых DBFS - достаточно будет к полям типа "Childs" добавить поля "Parents".

>Respect. Читать всем.

WIKI канкретно рулит.

> а где же тогда файлы лежат? Кто-то же их куда-то положил! Или всё-таки свалка по принципу "всё гамузов в одном месте"? Но тогда причём тут графы или их "деревянные" подмножества?

Ответь, где сейчас физически лежат файлы. И зачем структура каталогов нынешним ОС, если на жёстком диске они всё равно лежит одной кучей.

>Пользователь получит какие-нибудь преймущества при переходе с <что-там-на-MacOS> на DBFS?

Ладно, так и запишем, с большими объектными системами как программист ты не работал. Как пользователь дальше запуска отдельного файла из отдельного каталога, кажется, тоже.

Так о чём спор тогда? О вкусе апельсинов, которых не ел?

> Значит для iTunes DBFS просто бесполезна.

Для тебя - да. конец разговора.

> ...Которая есть костылем и для FAT12, и для FAT16, JFYI.

Её M$ разрабаьывала для СВОИХ (!!) файловых систем, причём сделать это было не так сложно - атрибуты немногочисленные и фиксированные, новых никто добавлять не будет. И то - сколько было победоносных заявлений и попыток запатентовать.
Разница чувствуется или перефразировать ещё понятнее?
Этот довод работает как раз ПРОТИВ тебя, ибо демонстрирует большую сложность даже такой тривиальной задачи.

у кого кто спер

> Осталось вспомнить, у кого идею спёр Microsoft, и с флеймом можно будет завязать :)

С Mach содрали, вестимо, как и многие другие куски NT с него же содраны.

>> Вы в "правильно спроектированной ДБ" все данные сваливаете в одну таблицу? Что-то мне подсказывает, что нет. Так почемы вы считаете, что свалка всех файлов в один каталог это хорошо и правильно?

> Это просто речь о скорости выборки. Хорошо, пусть будет не миллион файлов, а 100, но при 1000 чтениях и желательно, при этом без тормозов. Для БД - плёвое дело. Для FS - уже напряжно. И это ещё без учёта расширенных атрибутов. Ну-ка, найди мне средствами одной FS все песни 2001-го года из 4000 песен, хранящихся на диске? В DBFS - дело одного запроса.

$ ls music/by_year/2001

Но это, конечно, из разряда шуток в которых есть доля шутки.

Основная проблема при Вашем DB подходе в том, что сии "расширенные атрибуты" некому создавать/заполнять/поддерживать.

Пока они храняться в приватной базе данных (как и деляет, судя по Вашему описанию iTunes) -- то там можно ваять всё что угодно, подвтраьвая/оптимизируя структуру данных под всои нужды и не опасаяси повалить какое-то другое приложение (возможно, и скорее всего Вам неизвесное вообще).

Если же они лежат в public месте, которое шарится между разными приложениями, то конфликт по именам этих атрибутов с потерей работоспособности одного из приложений просто вопрос времени. И хорошо если оно просто отказалось работать. А если всё-таки заработало, но выдавая неправильные результаты, что тогда?

Третье: допустим у нас есть набор файлов. у каждого файла 20 атрибутов. И 20 приложений. Т.е. каждое придожение имеет по одному атрибуту в метаданных файла (кто-то хранит год, кто-то -- размер, кто-то -- контрастность...) Фактически, у нас появляется таблица с 20-тью полями и все они проиндекированы. Вы можете представить себе производительность на insert/update/delete такой таблицы в БД? Да и производительность на select теже под вопросом, ибо совершенно не понятно, насколько этот индекс будет селективен.

ты мне предлагаешь за каждым созданным файлом бегать??? :-)))

если пользователю позволено писать в какую-либо директорию, то он наклепает вложенных директорий кучу. в том то и дело, что насоздав кучу всякой фигни в отведенном для этого месте, плюс имея temp и home, он сохраняет файлик, на завтра забывая, как он его обозвал и куда положил, т.к. имеет быструю ссылку на часто открываемый документ.

> Этот довод работает как раз ПРОТИВ тебя, ибо демонстрирует большую сложность даже такой тривиальной задачи.

Извини, но наверно не против меня. Верно, с кем-то меня спутали.

Меня немного удивила сама постановка вопроса, сможет ли ФАТ12 понять длинное имя файла. Голая, девственная ФАТ12, и даже ФАТ16 этого, конечно же, не смогут (CVF тоже требует, кажись, костыля). С костылями в виде VFAT либо UMSDOS -- смогут обе. Только вот костыль в виде VFAT не то что лечить не может, он сделает инвалидом на всю жизнь, настолько криво он реализован. Сам пробовал врубиться в структуру, так при этом вспоминалась мысль о том, что мертвецов не оживляют, а в гроб заколачивают -- и в землю.

>Основная проблема при Вашем DB подходе в том, что сии "расширенные атрибуты" некому создавать/заполнять/поддерживать.

Вот не потому ли MS так долго возится с WinFS и теперь уже не обещает её даже в первом релизе Лонгхорна. Нужно же сделать будет чтобы хотя бы весь стандартный софт с ней работал.

Напомню, что совсем недавно было время, когда массовый софт напрочь не понимал имена отличные от 8+3...

Тут главное - раскачать и подтолкнуть.

А что инерция будет огромной - так по этому топику видно :)

это всё хорошо... а собрать ентот dbfs пробовал кто-нибудь? ... make -C c-api make[1]: Entering directory `/home/stiblo/RPM/BUILD/dbfs-v302/ocamldbfs/c-api' libtool --mode=link gcc -g -o example main.o -ldbfs gcc -g -o .libs/example main.o /home/stiblo/RPM/BUILD/dbfs-v302/ocamldbfs/c-api/.libs/libdbfs.so -Wl,--rpath -Wl,/home/stiblo/lib /home/stiblo/RPM/BUILD/dbfs-v302/ocamldbfs/c-api/.libs/libdbfs.so: undefined reference to `enter_blocking_section' collect2: ld returned 1 exit status make[1]: *** [example] Ошибка 1 make[1]: Leaving directory `/home/stiblo/RPM/BUILD/dbfs-v302/ocamldbfs/c-api' make: *** [c-api] Ошибка 2

... moc/moc_mainwindow.cpp g++ -o qtdbfs .obj/filterwidget.o .obj/keywordwidget.o .obj/customwidget.o .obj/searchwidget.o .obj/datewidget.o .obj/switcher.o .obj/dbfsview.o .obj/mainwindow.o .obj/main.o .obj/qmake_image_collection.o .obj/moc_filterwidget.o .obj/moc_keywordwidget.o .obj/moc_customwidget.o .obj/moc_searchwidget.o .obj/moc_datewidget.o .obj/moc_switcher.o .obj/moc_dbfsview.o .obj/moc_mainwindow.o -L/usr/lib/qt3//lib -L/usr/X11R6/lib -ldbfs_cpp -lqt-mt -lXext -lX11 -lm /home/stiblo/RPM/BUILD/dbfs-v302/ocamldbfs/c-api/.libs/libdbfs.so.0: undefined reference to `enter_blocking_section' collect2: ld returned 1 exit status make: *** [qtdbfs] Ошибка 1

>> Юзер должен _ДУМАТЬ_, а если не умеет этого делать то ему самое место работать дворником или еще кем-то в этом духе - где думать не надо. Если человек пришел на работу и ему надо иметь дело с компутером - то он должен знать как им пользоваться и задумываться иногда что он делает а не жмакать как обезъяна кнопочки и иконки - если он не умеет им пользоваться и не думает , то он на этой работе никому не нужен - это единственно правильный подход.

ты работаешь в организации до 20 чел, я угадал? :-)))

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

>>Ну-ка, сбацай мне запрос для поиска файла со словом "лопата" на >>тайском?

>Опять это слово "файл"? Ну не нужен он - значит нет нужды его искать. >Вот поиск лопаты - нужное дело.

Бред. Опять конь в вакууме. Отправлять по почте ты что будешь лопату или документ (то бишь файл) ее содержащий ?

> Напомню, что совсем недавно было время, когда массовый софт напрочь не
> понимал имена отличные от 8+3...

Ну, там-то значительно проще было, согласись. А тут вообще неясно - оставлять пункт меню "File -> Open" или сразу делать "Documents -> Search for your document" :)
Кстати, кто-нибудь - та же M$, пытается создать список СТАНДАРТНЫХ атрибутов, которые рекомендованы к импользованию теми или иными типами приложений? Иначе ведь такой зоопарк будет!

>>Опять это слово "файл"? Ну не нужен он - значит нет нужды его искать. >Бред. Опять конь в вакууме. Отправлять по почте ты что будешь лопату или документ (то бишь файл) ее содержащий ?

Документ - да. Файл - нет. Традиционно под файлом понимается "физическое воплощение" документа. Можно, ведь, пойти дальше и сказать - "по почте ты будешь посылать лопату или содержимое определённых секторов жёсткого диска?"...

> Отправлять по почте ты что будешь лопату или документ (то бишь файл) ее содержащий ?

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

> Документ - да. Файл - нет. Традиционно под файлом понимается
> "физическое воплощение" документа. Можно, ведь, пойти дальше и сказать
> - "по почте ты будешь посылать лопату или содержимое определённых
> секторов жёсткого диска?"...

А как ты собираешься оценивать размер этой мыльной лопаты, чтоб знать - получит её человек на самом деле или его pop3 скажет "иди на ... со своими 178 МБайтами"? Это хорошо, если лопата одна. А если надо их 10 послать? Перебором? Комбинаторику изучал? :)

>Ну, там-то значительно проще было, согласись.

Соглашусь. Но и от появления каталогизированных 8+3 до FAT32/VFAT прошло ~7 лет. А вот после FAT32 прошло уже 9 лет и о нововведениях пока только слухи. Учитывая нелинейный тем роста возможностей вычислительной техники и офигенный взлёт влияния MS в плане задания стандартов - это огромный срок. Подчёркивающий и огромную сложность задачи.

>А тут вообще неясно - оставлять пункт меню "File -> Open" или сразу делать "Documents -> Search for your document" :)

Я бы сделал и так и эдак. Т.е. у каждого файла есть атрибуты "name" и "parent(s)", которые позволят открыть его как и из заданного каталога, по имени, так и по прочим атрибутам :)

>Кстати, кто-нибудь - та же M$, пытается создать список СТАНДАРТНЫХ атрибутов, которые рекомендованы к импользованию теми или иными типами приложений? Иначе ведь такой зоопарк будет!

Думаю, предусмотрят не только стандарт на атрибуты, но и стандарт на введение новых. Повторюсь - прикрутить атрибуты к ФС - это полгода ненапряжной работы одного человека (пример - моя CMS). Мне же кажется, что они в это вбухивают человекоресурсов на порядки больше. Так что и работы пусть не на столько же больше там, но тоже - на порядки :)

DBFS - не только объекты-файлы с атрибутами. Но и новая идеология, новые средства работы и т.п.

>А как ты собираешься оценивать размер этой мыльной лопаты

Один из её атрибутов, обрабатываемых операционкой, будет size Кстати, это и в нынешних FS есть. Во всех даже, наверное. Если ты не знал.