Не хочу странного

пони маешь, для малого числа клиентов, файловые системы выигрывают у SQL, отсюда видимо и не делают

Всякие selfhosted clouds давно есть и работают.

Не хочу странного_._

Я за бан

операционные системы тоже есть и работают, причём тут оно?

Они для любого числа клиентов выигрывают у SQL, вопрос не про скорость.

пофиксил

Было уже в разном виде в fuse и ранней бете висты. Не взлетело.

Оно делает то, что ты хочешь, правда там браузер вместо фм.

правда там браузер вместо фм.

this. это не то, совсем не то

fuse вообще про другое

ранней бете висты

никто не видел, значит, не было

Неть! Для большого числа клиентов СУБД эффективнее, за счет балансирования RAM, очередей и вот этого всего

Это на сложных запросах фрагментированных данных.

Ну, а как ты хочешь, чтобы взял и появился фм с нужными тебе фишечками? Они решают одну конкретную задачу с известными 50+ лет параметрами, а ты хочешь чего-то странного, почему они должны взять и начать реализовывать всякое странное типа тегов и пр. и как они будут все эти метаданные стандартизировать на уровне фс? Это просто не того уровня задачи.

Ну если кто-то готов проспонсировать разработку, то почему бы и нет. Всего-то Qt5 и ORM, на любом удобном языке.

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

P.S. По ссылке много неинтесных буков, не читал.

sql это проста вид запроса к данным, скорость одинаковая что ты данные прочитаешь sql запросом, что по имени файла

фс и sql ортагональные понятия, ну и да бд на 1м клиенте могут работать в 100 раз быстрее чем фс(за счет индексов которые ускоряют поиск во много раз)

1)Никому не надо, сделать то это легко
2)Есть люди которые хранят файлы в бд
3)Можно хранить файлы не в бд но добавить к ним индексы, и через sql или любой другой язык получать к ним доступ

Не делают по двум причинам
1. Тёги как правило иерархичны /$HOME/Musice/Group/Albom и в отдельной ФС по этому нет смысла.
2. Запрос к тёговой ФС сводится к

ls -Ra /root_tagfs_patch |grep : | grep tag_1 | grep tag_2

SQL БД, умеющий в ней хранить файлы и из неё же их открывать?

Это хотели сделать в Lonhorn.

Но опыт показывает, что тот кто не может навести порядок в FS в BD свалку создаст еще быстрее...

А почему упоротым, не умеющим пользоваться gnu ln, до сих пор не придумали файловый менеджер, работающий с SQL БД, умеющий в ней хранить файлы и из неё же их открывать?

А почему ты из моих слов про дублирование решил в той теме, что не умею? Не не умею, а банально лишние телодвижения, так что иногда проще лишний раз Ctrl+S нажать в браузере, чем в консоли ln с путями набирать, тем более для каталогов хардлинки не получатся, а при сохранении много всяких мелких файликов получается. Симлинки же не всегда желательны.

Ну, я оказался прав. Вместо того, чтобы удобным образом делать это из своего любимого файлового менеджера (в дельфине, например, простым перетаскиванием), вы собрались «в консоли с путями набирать».

Симлинки же не всегда желательны.

с этого места поподробнее

crutch_master InterVi WitcherGeralt

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

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

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

Да но BD не только SQL. Amazon S3 как вариант...

Ха. А 1) Потоки были в старой Mac OS (forks) 2) Потоки есть в NTFS где хранят ACL например - храни там хоть черта лысого. 3) Наш любимый душегуб позволил сделать file.txt/.../имя_потока

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

Лет уже надцать как реализован Уже в VAX были задатки...

Я не понял нифига. Что за потоки?

Приплыли.... https://ru.wikipedia.org/wiki/Альтернативные_потоки_данных

https://en.wikipedia.org/wiki/Resource_fork

Я когда-то так музычку рейтил, да, помню. Давно прост было.

Но я же не об этом говорил, а об интеграции файлменеджеров со встроенными метаданными.

А где кроме NTFS они есть или у нашего любимого душегуба? Это вопрос номер 1. Вопрос номер 2, а как ты думаешь почему их нет в ext4? Да потому, что проблема яйца и курицы. Не скажу за «всю одессу». Назови мне ОСНОВНОЙ ФМ для Linux? Для Оффтопика? Ты хоть понимаешь процент пользователей FAR или Како он там графическое убожество? А 7zip поддерживает потоки?

Тоесть Те кто о них задумались это единицы. В Москве об этом думает 10 человек. 10!!! На 15 млн. Из 15 млн 8 используют файл менеджеры. А теперь я коммерческая компания типа МС. Оно мне надо?

Я Опенсорс проект и я решил сделать такой FM и что? Сколько народу будет им пользоваться? Это 10-20 лет и то если я буду писать его на Электроне. Короче это БЕЗСМЫСЛЕННО...

Я же говорю встроенные метаданные, а не вот это вот сбоку.

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

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

вы, очевидно, спросоня перепутали «заполнять» с «запоминать»

вы собрались «в консоли с путями набирать».

Использую mc, в общем все это лишние телодвижения.

с этого места поподробнее

вернее софтлинки, правильнее. Могут отваливаться при копировании.

Использую mc

там это делается одной кнопкой

в общем все это лишние телодвижения

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

Могут отваливаться при копировании

могут

для себя я в сабже не вижу смысла

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

почему их нет в ext4?

Есть xattrs

Там значение атрибута 64 kb

А сколько надо?

В NTFS и вроде как в поделии нашего любимого душегуба ограничений нет (ну как и основной поток)...

фс и sql ортагональные понятия, ну и да бд на 1м клиенте могут работать в 100 раз быстрее чем фс(за счет индексов которые ускоряют поиск во много раз)

Тебе рассказать про кеш ФС?

Если это для метаинформации, то много не надо.
Но да, это всё оправдания, xattrs здесь проигрывают. Хотя не знаю, где используются, или можно использовать ADS большого размера. Например, можно реализовать такой необычный способ прятать прон.
Но имхо, ограничение на длину имени файла в 255 байт (по сравнению с символами UTF-16 в NTFS) более существенно

Например, можно реализовать такой необычный способ прятать прон.

Я по сети открывал поток «bigblob» и писал туда столько данных, что на сервере заканчивалось место. И потом угорал над сисадмином. Файлы занимают 30%, а места меньше 10%...

Ограничение xattrs На имя атрибута ТОЖЕ 255 байт. Еще надо понимать, что поделие нашего любимого душегуба работало из обычного shell и в принципе не требовало модификации ПО (как NTFS).... Ну и тегов можно за 64 кб напихать - только начни.... В потоке можно хранить превью битмап например. Или фрагмент звука. К документу можно повесить цифровые подписи не меняя формат. Причем подписи ВСЕХ кто над ним работал.

до сих пор не придумали файловый менеджер, работающий с SQL БД, умеющий в ней хранить файлы и из неё же их открывать?

Для алфа-версии windows nt 5 была такая идея, во-время опомнились, сумасшедших подлечили.

Яж выше про лонгхорн писал