Как мы столкнулись с (иерархической) файловой системой в качестве базовой структуры данных?

19

Я самоучка, и у меня нет степени CS. Чем больше я узнаю о структуре данных, тем больше мне интересно, в наше время, как мы все еще обременены файловой системой, каталогами и файлами, как базовой структурой хранения данных в ОС?

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

Например, если бы я мог иметь собственные теги для файлов, где я мог бы помечать изображения, диаграммы, документы для обработки текста, весь репозиторий кода, все как принадлежащие одному проекту, это было бы действительно полезно для меня. Так как я застрял в парадигме файловой системы, я знаю, что мог бы поместить все это в одну папку / каталог, но что, если они уже существуют в разрозненных каталогах, и они должны оставаться там? Я знаю, что есть программы, которые могут это сделать, но почему они не находятся в файловой системе?

Что-то, что было бы неплохо иметь, это какая-то реляционная особенность в файловой системе, как вы получаете с RDBMS. Я понимаю, что это должно было быть частью Vista / 7, но это также выпало из списка возможностей.

Конечно, любая программа может хранить бинарный файл и иметь любую необходимую ему структуру данных. Почему ОС не может предложить более сложные способы хранения данных, кроме простой иерархии файловой системы?

user1936
источник
2
Суть его должна быть простой. Необязательный наворот, который вы упоминаете, должен идти поверх простого ядра. В качестве альтернативы, подождите два десятилетия, и кто-то изобретет понятие файловой системы.
Работа
3
«что если они уже существуют в разрозненных каталогах, и им нужно там оставаться?» Иногда вы можете использовать жесткие ссылки для решения этой проблемы ...
FrustratedWithFormsDesigner
1
Кроме того, некоторые интересные чтения по этой теме: c2.com/cgi/wiki?FileSystemAl Альтернативы
FrustratedWithFormsDesigner
3
Не совсем решение для Windows 7, но новые библиотеки могут дать вам некоторые функции, которые вам интересны: lifehacker.com/#!5464350/…
DKnight
1
Если я хочу поместить файл в две разные папки одновременно, я добавляю ярлык для этого файла в одну. Недостатком является то, что если вы переместите эту папку / файл, ярлык будет недействительным.
Матеин Улхак,

Ответы:

17

Начните с этого: http://en.wikipedia.org/wiki/Unix_File_System

Прочитайте это: http://www.unix.org/what_is_unix/history_timeline.html

Тогда прочитайте это: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

Есть простой ответ: «Почему ОС не может предложить более сложные способы хранения данных, кроме простой иерархии файловой системы?»

Потому что это слишком много для ОС.

Для этого предназначены библиотеки и пакеты приложений.

Например, Oracle продаст вам набор функций, подобных файловой системе, которыми вы управляете с помощью набора инструментов Oracle.

Python использует библиотеку DBM для создания очень сложных структур хранения на диске.

CouchDB и Mongo (и другие) - очень сложные структуры хранения, которые предлагают некоторые функции, подобные базам данных.

Дело в том, что ОС должна делать минимум, а все это надстройка.

С. Лотт
источник
4
Совершенно согласен. На самом деле, многое из того, о чем просил OP, присутствует в любом из мертвых или умирающих проектов WinFS: en.wikipedia.org/wiki/WinFS . Столько, сколько придурок говорит, «Аккуратно!» опытный пользователь и инженер-программист во мне говорит: «Слишком стараюсь!»
Адам Кроссленд
6
«Дело в том, что ОС должна делать минимум, а все это надстройка». Довольно смелое утверждение в эпоху, когда некоторые операционные системы содержат встроенную систему управления окнами, службу индексирования файлов, медиаплеер, удаленный рабочий стол, брандмауэр или Netris.
biziclop
1
@biziclop: Согласен. Windows отошла от точки зрения Linux. Ничего удивительного там нет.
S.Lott
1
@ S.Lott Не поймите меня неправильно, я согласен с вашим подходом, но в любом случае Windows обременена таким количеством бесполезного мусора, одна дополнительная функция не изменит ничего. :)
biziclop
4
Это философия Unix. Это не обязательно правильно. Это (и компилятор C) делает Unix простым для переноса на оборудование. Это также делает достаточно простым, чтобы люди клонировали Unix во вкусы -ix, которые мы находим сегодня. Если функция полезна, и она нужна всем программам, как, скажем, поля ввода с проверкой орфографии, то имеет смысл обеспечить ее в среде выполнения. Нам не нужно 400 независимых версий ленты.
Тим Уиллискрофт
8

Краткий ответ: каждый день люди понимают файловую систему. Это напоминает им о картотеке. Подумайте о веб-страницах и даже о толстых приложениях. Почему вы думаете, что Tabsони так популярны? Люди могут идентифицировать себя с ними и быстро понять их.

Imaging пытается научить бабушку искать файл в БД по тегам свойств. С файловой системой бабушка знает, что файл находится там, где она его положила .

Даже с WinFS я не думаю, что MS собиралась избавиться от внешнего вида файловой системы.

Идиоты
источник
9
Я должен не согласиться с этим. Большинство людей, которые не вынуждены перемещаться по файловой системе, не делают этого. Они открывают текстовый процессор и щелкают по последнему документу или выполняют поиск в меню «Пуск» Windows 7 и т. Д. И многие люди теряют место, куда они помещают свои файлы. Бабушке было бы намного проще искать «рецепты печенья» или «фотографии внуков» или что-то еще, чем поддерживать иерархию папок.
Матфей, ​​прочитанный
16
Это может стать для вас шоком: обычные люди не понимают файловую систему. У них нет самых слабых идей. И я имею в виду не ФС в стиле Unix с его точками монтирования, символическими и жесткими ссылками, а стандартную структуру каталогов с болотами и файлами в ней.
Бизиклоп
2
@ Мормонс, моя бабушка никогда не знает, куда она кладет вещи. Gmail уже переместил мою желаемую парадигму в систему тегов, особенно с фильтрами для автоматического тегирования вещей. Я думаю, что парадигма файловой системы была реализована в значительной степени из-за простоты программирования древовидных структур. Это также облегчает адресацию с точки зрения программирования. Как бы вы указали местоположение документа в системе на основе тегов? Не сказать, что это невозможно, но детали нужно прояснить.
zzzzBov
3
Приобретаете ли вы картотечные шкафы, заполненные тысячами папок и документов, необходимых для работы самого шкафа, по которым вы должны ориентироваться, но не прикасаться к ним? Кажется, ваша картотека открывается в другое место каждый раз, когда вы выдвигаете ящик? И т. Д. И т. Д. Я согласен с Мэтью и Бизиклопом: «Каждый день» люди не понимают.
Николь
2
У меня есть степень CS. Но я не знаю, в какие папки какая-либо Windows помещает какие файлы. Особенно Desktop, StartMenu, QuickLaunch и все другие пользовательские / системные папки по умолчанию. (Эта система M $ -Help не помогает объяснить мне, как нажимать кнопку.) Мне нужно установить CygWin, чтобы иметь возможность искать мои собственные файлы, потому что новые функции поиска M $ больше не находят простые существующие файлы, такие как на win2k. Отключение ошибок, таких как hide-system-files, hide-file-extensions, больше не решает большинство проблем. Я отказался от Windows, когда меня заставили работать на (совершенно новом) winXP.
комонад
6

Здесь есть доля правды в каждом ответе, но я не думаю, что это вся правда.

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

Люди не понимают древовидную файловую систему больше, чем понимают основанную на DAG.

И нет абсолютно никаких оправданий для жалких дополнений имен файлов, называемых расширениями. Они не только совершенно не подходят для своих целей (с указанием типа файла), но и являются бесконечным источником неудобств для пользователей.

Причина, по которой мы до сих пор их используем, - это смесь подхода «это подойдет» и реальной необходимости поддерживать совместимость со старым кодом. Новый подход к хранению файлов будет означать радикальные изменения в базовом API файлового ввода-вывода, делая большую часть существующего кода бесполезной. Либо это, либо вы должны ходить на цыпочках вокруг них, поддерживая устаревший API. Помните PROGRA ~ 1.

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


Теперь я собираюсь перейти на другую сторону.

Поскольку все вокруг нас, мы никогда не понимаем, насколько мощна метафора дерева. На моем жестком диске у меня есть несколько сотен тысяч файлов. Если мне нужно его найти, это редко занимает больше минуты, даже если я очень мало знаю о файле. Теперь представьте себе ту же задачу без какой-либо структуры, просто список имен, бесконечно прокручиваемый.

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

На самом деле, я однажды реализовал хранилище документов с богатыми метаданными и иерархией на основе DAG. (Это был даже не DAG произвольной формы, это была строго двухуровневая метаструктура и документы, которые могли быть дочерними для коллекции уровня 1 или уровня 2. Так что это действительно просто.)

Очевидно, что требование о том, что имена документов должны быть уникальными в пределах коллекции, должно было остаться.

И тогда проблемы начали течь. Что если вы откроете коллекцию и измените имя документа на то, что конфликтует с другой коллекцией, к которой также принадлежит документ? Мы отобразили сообщение об ошибке, но пользователи были совершенно сбиты с толку. (Это те самые пользователи, которые просили об этом требовании.)

Они пытались удалить документ, но все, что было сделано, это удалить его из коллекции. Таким образом, это все еще обнаружилось в результатах поиска. Мы попробовали это и наоборот, но потом они жаловались, что они удалили документ из коллекции A, и он волшебным образом исчез из коллекции B. Поэтому нам потребовалась и операция «unlink» и операция полного удаления.

В конце концов мы уступили поражение, к счастью, еще вовремя.

Тем не менее, дополнительные аспекты поиска, которые сделали возможными метаданные, сработали абсолютно.

biziclop
источник
Rememebr CP / M на жестком диске 5 МБ? Прошли сотни и сотни файлов. УЖАСНО!
quick_now
@quickly_now Ах, старый добрый CP / M. :)
biziclop
3

Честно говоря, я едва касаюсь метаданных в моих файлах на Mac. Я думаю, что за последние 5 лет использования OSX (который поддерживает комментарии и т. Д.) Я использовал метаданные, возможно, для 2 файлов. Не сказать, что это плохая идея.

Я просто не уверен, насколько прагматичны накладные расходы для тегов.

Я думаю, что самая приятная особенность файловой системы, о которой я знаю, - это система управления версиями на уровне файловой системы, которая работает между разделами. Это было сделано на VAXen в 70-х и начале 80-х, не зная, почему он не завоевал популярность в Unix и NTFS / Windows.

Пол Натан
источник
Современные версии NTFS / Windows сделать предложение версий. Это не совсем в твоем лице, но оно существует. Не могу сказать, как он сравнивается с VMS.
Shog9
2

Я работал с неиерархическими файловыми системами на старых версиях, таких как HP3000 и Encore / Gould. У вас не было каталогов; у вас была группа и учетная запись, а файлы назывались « group . account . file », например, «users.jbode.myfile1», «dev.jbode.main» и т. д.

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

Джон Боде
источник
1

Я не вижу, где (по крайней мере, некоторые) текущие файловые системы действительно должны сделать много [Edit: что-нибудь, чтобы быть честным], чтобы поддерживать теги. Когда вы приступаете к этому, поддержка тегов означает немного больше, чем некоторые дополнительные данные, связанные с файлом, но не записывается в поток байтов для этого файла.

NTFS (чтобы выбрать один пример, который широко используется) может сделать это просто отлично: что касается NTFS, файл не обязательно является одним потоком байтов. В NTFS вы можете связать произвольное количество потоков данных с одним именем файла. Каждый файл имеет (возможно, пустой) «первичный поток», который не имеет имени. Однако он также может иметь произвольное количество других потоков, каждый из которых должен иметь имя. Используя это, было бы действительно тривиально добавить поток с именем (только для примера) «теги» в существующий файл и (очевидно, достаточно) записать ваши теги в этот поток.

После этого наступает несколько более сложная часть: заставить ваши инструменты использовать теги, которые вы там поместили. В идеале, вы, вероятно, захотите проиндексировать их для быстрого поиска, чтобы вы могли делать такие вещи, как создание «виртуального каталога» из всех файлов с определенным тегом.

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

Если бы мне на мгновение позволили быть циничным, я бы сказал, что неизбежно, что эта функция NTFS останется почти полностью проигнорированной и неизвестной. В конце концов, он прост в использовании и не требует специального API или чего-либо еще. Вы можете использовать его в полностью переносимом C, C ++ или любом другом, что позволит вам указать произвольное имя файла. Вот небольшой фрагмент кода, демонстрирующий создание файла с AFS:

#include <fstream>

int main() {
    std::ofstream out("test.txt");
    std::ofstream tag("test.txt:tags");

    out << "This is the output file";
    tag << "tag1 tag2";

    return 0;
}

И вот код для чтения и отображения тегов:

#include <fstream>
#include <iterator>
#include <iostream>
#include <string>

int main() { 
    std::ifstream tags("test.txt:tags");

    std::copy(std::istream_iterator<std::string>(tags),
          std::istream_iterator<std::string>(),
          std::ostream_iterator<std::string>(std::cout, " "));
    return 0;
}

Все очень просто и легко. Обратите внимание, что, хотя я написал только тривиальный бит данных, вы можете рассматривать AFS как любой другой файл - все обычные «вещи» работают так же, как и все остальное. При обычном отображении каталога все, что будет отображаться, - это первичный поток (например, размер, показанный для файла, будет размером первичного потока), но, если вы хотите его увидеть, dir может также отображаться информация об альтернативных потоках. с /Rфлагом. Например, листинг для файла, созданного выше, выглядит так:

03/16/2011  08:22 PM                23 test.txt
                                     9 test.txt:tags:$DATA
               1 File(s)             23 bytes
Джерри Гроб
источник
1
DIR может показать это, но резервное копирование файла с альтернативными потоками ужасно сложно , особенно для какой-то другой системы. Например, сегодня большинство накопителей NAS используют Linux, а файловые системы там вообще не обрабатывают альтернативные потоки. Скопируйте файл поверх ... и все остальное исчезнет.
quick_now
Да, я заметил, что большинство систем NAS довольно ... сложны (и это не единственный способ). Что касается фактического резервного копирования и восстановления, то это не вызывает проблем (по крайней мере, если соответствующее программное обеспечение написано грамотно): BackupReadсериализует все потоки и BackupWriteвосстанавливает файл (с альтернативными потоками) из Серийный формат.
Джерри Гроб
Зависит от того, хотите ли вы, чтобы файлы резервных копий были непосредственно читаемы на NAS. Если вы делаете (и избегаете необходимости в специальных программах восстановления), то вы застряли с обычными файлами.
quick_now