Зачем нужны имена у файлов?

← →
iZEN © (2005-02-13 11:59) [0]

Я вот не понимаю, зачем нужны имена файлам, ведь особенно весело бывает, когда их приходится придумывать САМОМУ перед сохранением документа. Что, например означает такое имя: "Письмо к Вере <дата>.eml", когда этих писем может быть 10-20? Какое из них нужно посмотреть, чтобы вспомнить, что писали по поводу впечатлений от просмотра кино и какие цитаты приводили?

Нафик-нафик.
Имя файла - это его СОДЕРЖИМОЕ - оно, кстати, уникально, поэтому не может быть дублей, но для краткости можно использовать CRC (циклический код) - но это уже СИСТЕМНОЕ имя, которым система распоряжается и НЕ показывает пользователю.
Выходит, тогда и каталоги не нужны вообще, а файлы просто сваливаются в один большой "корневой каталог". Что там на ограничения в именах файлов? Про них больше НЕ слыхать!

А может это уже и не файловая система вообще?
Но данные-то есть и они должны быть как-то упорядоченны для пользователя! В самом деле, как же искать среди сотен тысяч "файлов с именами из CRC-кода" что-то нужное тебе или другому пользователю, причём система нарошно "прячет" CRC? Вроде всё есть, но ничего же не видно!! Такое могут придумать только в SymbianOS или PalmOS. Но и MS уже подумывает о некоей продвинутой системе хранения/поиска в будущей WinFS. А-а-а... :baaa :stupid

Но так ли опасна "новая философия"?
Некоторым (а скорее всего - БОЛЬШИНСТВУ) IT-товарищей такое положение вещей может резко сломать мировоззрение и внутреннюю философию восприятия компьютерных технологий и им ничего не останется как удалиться в монастырь или уехать в деревню заниматься сельским хозяйством, что, впрочем, одно и то же - до компов им больше не будет дела. Но так ли опасна "новая философия" оперирования информацией для всех остальных? Зададимся этим вопросом и попытаемся (те кто хочет) ответить на него здесь, в этой теме.

← →
Kerk © (2005-02-13 12:04) [1]

Вопрос: у меня есть копии одного и того же файла в разных папках? как можно лишать его имени, если содержание и CRC совпадают, а имена - разные.

А вообще твоя идея не лишена смысла.
Часто создаю файлы с именами вроде !qeqwe что б туда скопипастенный откуда-нибудь текст бросить... а имя придумывать лень... :)

← →
noobi$h (2005-02-13 12:05) [2]

ты болеешь

← →
uny © (2005-02-13 12:10) [3]

есть же программы придумывания паролей - можно их использовать для придумывания имена файлам.

[2] :)

← →
uny © (2005-02-13 12:11) [4]

имён файлам, конечно, просто смешно))

← →
Palladin © (2005-02-13 12:11) [5]

А давайте людей нумеровать... кстати на зоне так и делается по моему...

← →
Palladin © (2005-02-13 12:23) [6]

хотя про зону это я загнул... а так, сформируем корневую директорию из десятизначных номеров, а потом детей по поддиректориям будем оформлять...
"Уважаемый, 7:\2948224834\2\1\1\1\2, сообщаем Вам, что вы имеете задолженность по коммунальным услугам в размере 2 500 руб. что превышает указанный в договоре найма максимально допустимый предел задолженности. Необходимо погасить долг в течении одной недели, иначе дело будет переданно в суд.
Нач. АО 7:\4398723432\1\1\2\1"

Круто

← →
raidan © (2005-02-13 16:59) [7]

Нееее...
У всех людей должен быть уникальный числовой ID!
Чтобы поиск был быстрее.

← →
Vaitek © (2005-02-13 17:53) [8]

Ага, в 256 ричной системе счисления. Для совместимости 8-)

← →
iZEN © (2005-02-13 18:30) [9]

Что есть Каталог в современном представлении файловой системы - это тот же файл со списком других файлов и каталогов, всунутых туда по какому-то критерию. Ведь так?

Если так, то этот "критерий" можно предстаить полем в базе данных. А, как известно, чтобы получить данные из базы, удовлетворяющие условию совпадения (частичного) по определённому полю достаточно сделать сами знатете что (SELECT <критерий> FROM <таблица_базы> WHERE <условие>).

Так ведь Каталог и есть - ВЫБОРКА, но по ОДНОМУ критерию-полю - ИМЕНИ (ну, ещё можно отфильтровать по атрибутам).
А представьте себе, что можно делать выборку файлов по содержимому, задавая бесконечное множество "паттернов", которым удовлетворяет содержимое файлов - это уже тянет не на реляционное хранилище, но что-то принципиально новое (или старое?).

← →
Kerk © (2005-02-13 18:32) [10]

iZEN © (13.02.05 18:30) [9]

А как ты себе работу с такой ФС представляешь? Вот запускаю я FAR, а там... что?

← →
iZEN © (2005-02-13 19:18) [11]

Kerk © (13.02.05 18:32) [10].
А там нужно указать поля, по которым ты хочешь получить выборку по конкретному накопителю (Windows) или ресурсу (UNIX). И, оба-на: списочек отсортирован в лучшем виде.

1. Имена файлов накладывают ограничения на восприятие. И часто нельзя узнать наверняка, например, что внутри, не открыв файл — налицо бесполезность имени (метки).
2. При сохранении документа нужно явно придумывать имя, которое чаще всего либо несовсем чётко отражает содержимое, либо даётся "от балды" (по первому предложению в документе Word-а).
3. Музыкальные файлы используют ID3-тэги — это уже что-то. Два одинаковых музыкальных файла ищутся не по имени, а по содержимому и в ID3.
4. Картинки и изображения уж точно можно сравнить лишь по содержимому (CRC рулит).
5. Бинарники — то же самое — версионость для избежания DLL-hell.

← →
iZEN © (2005-02-13 19:23) [12]

Поля - это либо ID3-тэг(и), либо отрывок текста (шаблон), либо графический паттерн, снятый web-камерой/телефоном/др. (здесь уже подключается ИИ по распознаванию образов), бинарник находится по критериям "установленные программы" или другому паттерну (например, "продукт творчества какой-то среды программирования или инструмента").

← →
cyborg © (2005-02-13 19:28) [13]

Пить надо меньше!

← →
wicked © (2005-02-13 19:28) [14]

возможно, выскажусь и не по теме, но существенно её задену... а именно:

> 4. Картинки и изображения уж точно можно сравнить лишь по
> содержимому (CRC рулит).

CRC - не такой уж уникальный хеш, чтобы ним можно было однозначно идентифицировать те же файлы... когда я работал в "большой-страшной-конторе", меня посетила такая же мысль - перекодировать абонентов в БД системы, давая им в качестве идентификатора CRC по полю "имя-фамилия"... и от этой идеи пришлось отказаться по простой банальной причине - CRC совершенно разных абонентов совпадали... количество абонентов было около 65 тыс, при этом количество совпавших CRC достигало сотен... посему CRC совершенно не годится для идентификации... таким идентификатором мог бы выступать MD5, но здесь свои но: трудоемкое вычисление и размер 128 бит...
так что с технической точки зрения идея мало жизнеспособна...

← →
iZEN © (2005-02-13 19:38) [15]

К wicked © (13.02.05 19:28) [14].
К поиску картинок можно применить визуальный паттерн, показанный камере либо нарисованный от руки тут же. Согласитесь, если компьютер может пусть очень-очень приближённо выдать набор картинок, приблизительно совпадающих с росчерком Вашего пёрышка на планшете (в воздухе) (граффити знаtте?), то это уже прогресс!! ;))
Ну а по автору/названию картинки в тэгах - тем более не проблема.

← →
iZEN © (2005-02-13 19:42) [16]

К wicked © (13.02.05 19:28) [14].
По поводу уникального ID (типа CRC) в системе хранения.
Так он же вычисляется один(!) раз во время создания файла, может быть его стоит хранить в самом файле (в отдельном fork-e: MacOS и NT это позволяют)?

← →
Nous Mellon © (2005-02-13 19:48) [17]

> Я вот не понимаю, зачем нужны имена файлам, ведь особенно
> весело бывает, когда их приходится придумывать САМОМУ

Сам ответил на свой вопрос. Ты придуывашь их САМ и для СЕБЯ. В соотвествии со своим представлением о содержимом и назначением этого файла. Глядя потом на список ты уже без труда вспомнишь что хранится в милой сердцу "FotoElena.jpg" или ненавистном "Налоговыйотчет.doc". К тому же подзабытые уже архивы всегда выплывают в памяти, когда прощелкиваешь старые каталоги в ТС, натыкаясь на имена из прошлого. Точно также как речь человека, его привычка идентифицировать и наделять идентификаторами объекты окружающего одушевленного и неодушевленного мира делает его венцом творения. Идентифицировать можно по-разному, но почему бы не сделать это наиболее близким человеку способом. В конце концов -- не гавкать же нам, правда?

Вывод: Вопрос как минимум глуп.

← →
iZEN © (2005-02-13 19:55) [18]

К Nous Mellon © (13.02.05 19:48) [17].
У каждого человека свои критерии в назЫвании файлов. Если Вы скачаете с моего сайта страничку на свой компьютер и как-то раз при поиске в архиве файлов найдёте файл с названием FotoElena.jpg, то откуда Вы сможете узнать, что там не фото фашей бабушки (которую зовут Елена, допустим), а фото моей сестры?
Вы полезете ОТКРЫВАТЬ! Явно Имя - мимо цели. Нету у него уникальности.

Кстати, параллельная ветка на RSDN.ru более конструктивна:
http://rsdn.ru/Forum/Message.aspx?mid=1023595

← →
Ломброзо © (2005-02-13 20:34) [19]

Вполне разумные размышления, если речь идёт о больших объёмах информации. Если в домашней библиотеке книжек мало, хозяин знает, где и чего у него хранится "на ощупь". В библиотеке же приходится сперва лезть в каталог (первый фильтр), отбирать книги, знакомиться с оглавлением (второй фильтр), затем детально штудировать каждый источник, конспектируя (третий фильтр). То же самое в Яндексе. Недостаток поисковых систем - большой процент "шума" в выборках. Поэтому алгоритм интеллектуального индексирования ресурса по содержанию - сложная и вполне достойная задача. Кистате в Longhorn вроде как файловую систему обещают на движке MSSQL смастерить и приделать к ней полнотекстовый поиск.

Так шта... Открываете вы ФАР - а там текстбокс с кнопкой "Шарик, ищи!"

← →
iZEN © (2005-02-13 20:38) [20]

Уникальность файла, как правило, задаётся Именем_файла и путём_к_нему (file:/bla-bla-bla/myfile.ext). ВСЁ. Этот критерий сейчас применяется ВЕЗДЕ. Отсюда и дубли, неконтролируемые копии и изменения с файлом (на одном компьютере). Чтобы сделать Backup нужно избавится от дублей, иначе менеджер либо не пропустит файлы с одинаковым именем и потребует явного ручного разрешения конфликта имён (VCS), либо внесёт избыточную для пользователя информацию в архив.

Далее.
Обычный файловый поиск может дать выборку с сотней ничего не означающих файлов "pic.gif". А все они РАЗНЫЕ, и Вы будете каждый открывать чтобы удостоверится, что там кроме пиксела (для форматирования) ничего нет? Кроме того, часть файлов с таким именем могут иметь совершенно ОДИНАКОВОЕ содержимое. Что ж, их все придётся хранить? Для чего, какой смысл? Функция ХЭШИРОВАНИЯ_ПО_СОДЕРЖАНИЮ (CRC, в грубом приближении) позволяет избавится от избыточности хранения дублей однозначно и имя здесь одно - СОДЕРЖИМОЕ.

← →
iZEN © (2005-02-13 20:43) [21]

Идентификация объекта в новом ракурсе - это нечёткое узнавание. Вполне человеческое свойство. Этому и надо учить машины. Чтобы они хоть в чём-то могли понять наши нечёткие требования (выдать список близко совпадающий к запросу).

← →
Плохиш © (2005-02-13 21:18) [22]

>iZEN

Это, что, замаскированное предложение написать свою ос? Так флаг в руки и барабан на шею.

← →
Девушка © (2005-02-13 21:30) [23]

Зачем имена у файлов... что-бы они были файлами, ибо файл это - именованные данные. А если у них нету имени, какой тогда это файл?

← →
Vaitek © (2005-02-13 21:33) [24]

Это уже на файл, это "потерянный клайстер" Гы 8-).

← →
Ломброзо © (2005-02-13 21:37) [25]

Плохиш © (13.02.05 21:18) [22]
И как Вы с флагом собрались барабанить? (ну разве если только клювом)

Девушка © (13.02.05 21:30) [23]
Вы в тырнете URLы всегда запоминаете, если Вам не нужна однозначная идентификация ("покласть в закладки")? Речь идёт, насколько я понимаю (и не только я, но и MS, также заявившая о своём интересе на рынке поисковых мойшин с тем, чтобы сделать свой виндовс ещё более "распределённой" хехех), не о том, чтобы отказаться от файловых систем вообще, а о том, чтобы скрыть их более высоким уровнем абстракции.

← →
Девушка © (2005-02-13 21:52) [26]

> Ломброзо © (13.02.05 21:37) [25]

Файл, если не ошибаюсь, согласно определению это - именованная область данных.

Если область данных имени не имеет, то она не является файлом согласно определению.

← →
Ермак © (2005-02-13 22:05) [27]

2IZEN:

Вы определенно переработались с реляционными БД. Это понятно по нескольким Вашим фразам о полях, выборках и т.п. Вы приводите пример WinFS, как доказательство, что Микрософт идет от файловой системе к БД. Это действительно так, и действитедьно за технологиями БД будущее, однако вопрос в том, за какими именно БД? Не за реляционными, это уж точно. В системных технологиях применимы именно иерархические БД, то есть, не табличка с одной "корневой директорией", а те же самые корень, ветки-папки и листья. По этому принципу работают такие сервисы, как DNS, DHCP, Active Directory. Несомненно, WinFS будет универсальной БД, но именно такой, иерархической.

Если интересно, добавлю, что сейчас существует очень много сложных задач, для которых реляционные (табличные) БД почти не применимы. Это экспертные системы, БД для систем САПР, офисные БД, БД поддержки принятия решений, любые БД, требующие не просто большого числа простых транзакций, а интеллектуального анализа данных, в основе своей многомерных.

Мораль проста: познапкомившись с Interbase или Access, не следует вопить на каждом углу: даешь БД, даешь SQL! Наиболее перспективные БД - объектно-ориентированные и иерархические, сегодня это уже очевидно.

← →
Palladin © (2005-02-13 23:07) [28]

> иерархические

частный случай реляционной

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

> Это экспертные системы, БД для систем САПР, офисные БД,
> БД поддержки принятия решений, любые БД, требующие не просто
> большого числа простых транзакций, а интеллектуального анализа
> данных, в основе своей многомерных.

MS OLAP - кубы данных, в основе те же реляционные базы данных.

Не стоит забывать: есть данные, есть операции над ними. База данных, это набор множеств связанных друг с другом отношениями. Без этой связи они будут бесполезны. Отношения - это и есть реляционная БД. Как ты не их представляй (иерархически, объектно... как угодно) отношения никуда не денутся. Математика отношений думаю не изменится.

Это все имхо.

>Ломброзо © (13.02.05 21:37) [25]
>Плохиш © (13.02.05 21:18) [22]
>И как Вы с флагом собрались барабанить? (ну разве если только клювом)

Ну вот, клюв у Вас уже есть ;-)

Кубы данных.
Скорее Гиперкуб, так как измерения - "размытое", или "нечёткое" множество, которое может назвать пользователь. В таком кубике, между прочим, может поместиться вся "вселенная" конкретного индивида. Вполне уместно об этом говорить. Своими запросами пользователь может её одновременно и "исследовать", и "достраивать знаниями". Ментальные способы узнавания придётся тоже совершенствовать.

(вспомним фильм заодно :))

2Palladin:

"Иерархическая - частный случай реляционной". Смотря с какой стороны смотреть. На физическом и алгебраическом уровне действительно иерархическая может быть представлена через реляционную, но точно так же я могу перевести любую реляционную БД в термины иерерахической. Вопрос не в том, как физически хранить данные, а в том, как их разрабатывать, проектировать. Реляционная алгебра - вещь сильная, была совершенно необходима для проектирования БД в эпоху структурного программирования, тогда просто не было другого формального языка кроме алгебры чтобы формализовать разработку. Но реляционный язык - это лишняя прослойка абстракций, что не есть хорошо. Сегодня у информатики есть свой собственный язык конструирования - это термины именно ООП. Нотация Буча, UML и все иже с ними гораздо лучше подходит для формального описания информационных систен, нежели чистая математика, просто потому, что ближе к реальному миру. Представьте, что было бы, если бы архитектор-строитель проектировал здание не в терминах перекрытий, кирпичей, панелей, а в терминах множеств, отношений, операторов сварки-склейки-окраски? А ведь именно этим долгое время приходилось заниматься информатикам, просто из-за отсутствия другого подхода.

Конечно, я не претендую на абсолютную истину, просто мысли вслух...

> Модная, но до сих пор неопределенная объектная база данных...
> пока развивается из постулатов реляционной... Таблицы там
> просто наследуются... Постепенно превращаем данные и их
> отношения в объекты со всем вытекающим... реализованно все
> равно будет как раньше... интерфейс использования другой
> будет... этакая прослойка...
На самом деле уже примерно 10 лет существует достаточно проработанная реализация объектно-ориентированной базы. Сам не работал, но что-то слышал про это дело. Для решения многих задач оно, вроде бы, намного круче Оракла и иже с ним. Недостатки - отсутствие внятной документации, узкая специализированность на разработку медицинского софта. Но, в принципе, проект, насколько я понимаю, рабочий.
http://www.multivox.ru/pluk/default.html

> [30] iZEN © (14.02.05 01:35)

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

> [31] Ермак ©
> но точно так же я могу перевести любую реляционную БД в
> термины иерерахической.

Нет, не любую. Всякое дерево является графом, но не всякий граф - деревом.

Но в остальном согласен. Просто я не допонял о чем Вы пытались сказать :) Таже история с программированием, которое развивалось от машкоманд до ЯВУ и дальше... Объектная БД мне кажется наиболее перспективна...

>Нет, не любую. Всякое дерево является графом, но не всякий граф >- деревом.

Да, тут ты прав. Но я немного не то имел в виду. Перевести не в термины, а в реализацию. Я могу хранить ЛЮБУЮ таблицу в дереве - где поддеревья являются кортежами. Если листья в поддеревьях одинаковы, получаем обыкновенную таблицу из РСУБД. Иначе - таблицу с динамически меняющимися от кортежа к кортежу параметрами. Если же я ввожу в дерево поддержку ссылочного типа, то вообще получаю возможность зранить в дереве любой граф. Зачем? Для определенной категории задач моделирование деревом гораздо удобнее, чем множеством ненаглядных, слишком абстрагированных таблиц. В матстатистике и эконометрике используется как ключевое понятие именно таблица, однако на практике применить дерево было бы гораздо удобней. Прослеживается структура наблюдаемого объекта от самого верхенго к самому нижнему уровню, листьями дерева являются наблюдаемые показатели, каждый зранит свою историю и при необходимости выдает интерполяцию или прогноз... Пардон за многословность, просто я сейчас вплотную этой проблемой занимаюсь, о наболевшем, так сказать...

> Иначе - таблицу с динамически меняющимися от кортежа к кортежу
> параметрами.

Угу. Это уже не иерархия, это параметрическое рекурсивное дерево... это в реализации на столько трудно, даже не трудно, а вся трудность сводится к оптимизации реализации этого механизма...

тоже о наболевшем... этим сейчас и занимаюсь...

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

Возможно эта категория задач называется отчетность и анализ (с возможностью исправления или журналирования) логической модели базы? :)

Однако, штука в следующем:
1. система (разные ix-ы и Win yf NTFS) и так работает не с именами файлов, а с их идентификаторами. А все каталоги и имена - это не для системы. Это для людей.
2. Системы, которые юзерам виделись с плоскими каталогами или с одним большим каталогом были, и оказались довольно неудобны. Тем и славна Multics, что её идею иерархических каталогов использовали в UNIX. Ну, и поскольку M$ делали Xenix - то и ДОС-2 и т.д.
Однако, и в никсах, и в НТФС, если мне не изменяет склероз - сама система работает с одной громадной таблицей идентификаторов и ещё большей битовой таблицей секторов. Система каталогов же нужна только людям (программистам в том числе). Например, и в никсах и в НТФС очень даже запросто и штатно можно сделать файл, который будет одновременно виден в десяти разных каталогах под двадцатью разными именами. Поскольку имя файла - это для людей.
3. Сетевые базы (иерархические - их подкласс) интенсивно развивались. И даже существует стандарт CODASIL. Однако, как только Кодд разработал теорию РСУБД с сопуствующим языком запросов - кодасиловские базы быстро сникли, поскольку не смогли выдержать конкуренцию. Хотя в тот момент программистов учили думали именно категориями сетевых моделей и к РБД привыкать им было очень тяжело. Чем же так выиграла тяжёлая, непривычная, неинтуитивная и молодая-неразработанная реляционная модель у интуитивной, привычной, разработанной и к тому времени даже стандартизированной сетевой?

Чем? Тем, что тогда не существовало ООП, и проектировать базы приходилось в терминах математики. А математически описывать сеть... Бр... РСУБД тем и брали.

СЕйчас математическое проектирование не актуально, структурный анализ уходит в прошлое, ООП - повсюду... И это хорошо.

Зачем нужны имена у файлов? А можно вопросом на вопрос: а на фиг нужны адреса в Интернете? Может, IPшниками обошлись бы, и прекрасно?

Кстати, Интеренет - самая большая БД - построен именно на иерархических принципах. А может, надо было на реляционных? Писали бы сейчас в браузере: SELECT и т.д. Ну что, какая модель данных естественней и логичней?

Зачем нужны имена у файлов? Найти похожие ветки