Собственно, сабж.

На это указывает ряд моментов в существующих решениях.

Прежде всего, давайте вспомним, какими важными характеристиками обладает файл?

1. Размер. Любой классический файл имеет строго установленный и известный размер в произвольный момент времени. К файлам-устройствам вернемся позднее.

2. Файл хранится на одном логическом томе. Это следствие логической разбивки диска на тома, которые далее размечаются файловой системой. Другими словами, два обособленных куска на 2 физических машинах - это 2 файла.

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

Второе — это возможная децентрализованность. Другими словами, два или более потоков могут сливаться в один. Например, видеопоток в какой‑то момент может обогощаться аудио‑потоком. Картинка в картинке — это пример слияния нескольких видеопотоков. За обработку аудио и видео потоков могут отвечать совершенно различные программные и даже аппаратные решения.

Две разные части файла могут жить в разных томах где‑то на раиде. Но в этом случае эти две части представленны НЕ как файлы. И став файлом они присутствуют уже на ОДНОМ логическом томе как единый файл.

Сюда же можно отнести стримы ntfs, которые не признаются файлами разработчиком ОС (microsoft). Это‑ отдельный механизм, у него свой api, свой механизм хранения, стримы в файловом менеджере не видны. т. е. функции ос по работе с файлами эти стримы не видят.

Разработчики Linux‑подобных систем (думали что) выкрутились, придумав концепцию файла‑устройства. Здесь весь поток разбивается на сообщения некой длины, не превышающей заранее известного определенного максимального значения.
Но при необходимости долговременного хранения такие данные должны быть перемещены в обычные файлы. Что породило такие вынужденные приемы, как циклическая перезапись файлов в видеорегистраторах. т. е. когда пространство на диске заканчивается, видеорегистратор затирает самые старые файлы и на их место помещает новую информацию. И подобные ухищрения.

Таким образом, мы видим первое отступление от классической трактовки файла в пользу сразу двух механизмов, объединенных названием «файл».

Далее, что было. Как бы не хотелось использовать файлы‑устройства, для механизма сокетов tcp и udp придумали совершенно иное решение. В системе с концепцией «файл‑это все», Карл! Сокеты и данные из них никто в здравом уме не признает файлами ни в каком виде. API работы с сокетами — свое, не файлОвое. Дык почему же? Идеологи linux скромно обходят этот вопрос стороной.

Итого, в системе, где «все‑файл», далеко не все файл. И придумано это было очень давно (во времена bsd unix).

Также в стародавние времена на as/400 существовала операционная система с идеологией «все есть объект». т. е. вместо файлов данные хранились прямо в БД и этим данным можно было сопоставить некие функции и методы их обработки. Данные и методы как раз и трактовались вместе как «объект». Это считалось удобным.

Смотря в настоящее, я вижу попытки создания подобных объектных систем хранения. Например, documentum — промышленное ПО для хранения документов представлено объектным движком с sql‑подобным языком объектных запросов. В данном случае, любые данные могут храниться послойно и слои представляют собой иерархию наследования объекта.

Зачем это может пригодиться в потоке сырых данных? Первое — это метаинформация о самих данных. Она идет как бы в параллели от основного потока (напр. видео). Со временем, она может изменяться (напр. меняется разрешение видео).

Второе — даже в сокетах существует такое понятие как oob. Microsoft определяет oob, как логически обособленный канал передачи данных, связанный с каждой парой подключенных сокетов. Подробнее об этом и назначении — здесь.

Итак, мы видим, что даже механизм сокетов, изначально спроектированный под потоки, вынужден иметь некоторые расширения, связанные с параллельными потоками информации. А если потребуется oob номер 2,3? Видимо, существуют задачи, где есть такие потребности (в oob).

Можно ли такое реализовать в файле? Можно, если представить файл в виде некой стандартной структуры с несколькими направлениями хранения. Но при этом, файл становится мини‑базой данных. Примеры известны — word‑документ представляет собой базу данных для текстового документа. Сертификат — это asn.1 база данных информации о сертификате.

Но в контексте файла и ОС речь нужно вести о вводе такого стандарта хранения файла в ОС и обработку его средствами ОС. Насколько я знаю, та же microsoft не пошла этим путем, а просто сделала механизм стримов рядом с механизмом файлов. Почему — не знаю. Вероятно, посчитали, что так будет удобнее. Возможно, с годами планируют уйти от файлов и перейти на хранение в стримах.

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

Конечно, можно что‑то накостылить, но все попытки примирить файловую систему с современностью, видимо, будут расцениваться как «костыли». Потому что летать это будет «ниже и ближе» альтернативных решений. Стримы дают нам возможность облачного хранения информации. Чтобы то же сделать в файлах, нужно очень сильно переработать концепцию файловой системы.

В конечном итоге, полагаю, в файловой системе от файлов останется только одно название. Так может, не стоит и начинать?

Просто признайте, что файл — это не все и пилите «на здоровье» какой‑то прогрессивный механизм.