Господа сисадмины, есть ли для Linux - какая нибудь подсистема хранения метаинформации файлов независимая от низлежащей fs?

baloo? Правда, хз можно ли его настроить для хранения произвольной инфы.

Пост прочесть не смог, предлагаю попробовать Tracker.

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

Присоединюсь, что непонятное описание, но предложу вариант s3.

Присоединюсь, предлагаю SQLite.

Господа сисадмины, есть ли для Linux - какая нибудь подсистема хранения метаинформации файлов независимая от низлежащей fs?

Маленькая черная книжечка в сейфе.

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

оригинальное время модификации

Должно быть в метаданных самого медиафайла. Всякие baloo или recoll умеют их извлекать/искать.

а желательно ещё сохранять владельца и права доступа. Изначально вопрос «встал» после потери оригинальных времён медиафайлов

А ещё отдельное время создания, время правки и время доступа, которые в зависимости от ОС и ФС могут быть, а могут и не быть.

Да, вопрос поставлен интересно, грамотно, причём все предложенные решения — какие-то полуфабрикаты. Если baloo не поможет (я сильно сомневаюсь, что там есть функция принудительно восстановить атрибуты в слитом из облака бэкапе), есть смысл задуматься о создании отдельной программы для этого. Причём даже не только для Linux, а вообще: есть разные ОС, по которым кочует дерево файлов, поставлена задача сохранить те атрибуты, которые были в оригинальной системе.

свое облачное хранилище с историей модификаций - их же есть всяких. от оси клиента зависеть не будет…

Ты хранишь файлы в облаках вне шифроконейнеров? У тебя проблемы посерьезнее, чем какая-то дата модификации.

У ТСа и так проблемы посерьёзнее чем файлы на компьютере.

https://github.com/przemoc/metastore

metastore is a tool to store the metadata of files/directories/links in a file tree to a separate file and to later compare and apply the stored metadata to said file tree. It was originally written as a supplement to git, which does not store all metadata, making it unsuitable for e.g. storing /etc in a repository. metastore can also be helpful if you want to create a tarball of a file tree and make sure that «everything» (e.g. xattrs, mtime, owner, group) is stored along with the files.

Stored metadata metastore stores following metadata in its files:
owner,
group,
permissions,
xattrs,
mtime - optionally.

На скорую руку добавил поддержку atime и ctime: https://github.com/data-man/metastore/tree/other_times.

man не обновлял. :)

Вспомнился досовский descript.ion …
Но КМК решение в контейнеризации. Тарбол, образ диска, другое…

ЗЫЖ Тамбовский волк тебе господин лол. Не нужно вот этого вот антиконституционного экстремисьму супротив дидовского равенства.

был umsdosfs для хранения unix аттрибутов на fat, но сдох.

сейчас я бы сделал файл и смонтировал с -o loop или выставил бы как nbd, но не знаю как там с этим в сетевых хранилищах.

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

при копировании в новую фс он проставит текущие даты.

Сфигабы ? Или я не понял вашу мысль?

https://imgur.com/H3NeWki.png

в tar их, а потом в облако

типа отдельного файлика где все будет хранится

metastore так и делает, в собственном формате. А потом использует mmap.

Да, но modify у него как был так и остался.

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

Не только modify

Ты хранишь файлы в облаках вне шифроконейнеров? У тебя проблемы посерьезнее, чем какая-то дата модификации.

Нет у меня ни каких проблем. Взял по акции 2Т на 2года за 900р. Пихал всё что было лишнее, а удалять с ходу не хотел. В фотобазе ни чего криминального, пусть смотрят. В своё время flickr давал 3Т нахаляву, я лил свою фотобазу туда но flickr слился - зря потратил время. В общем то из за фотобазы и началась засада... Есть конечно и локальная копия с честным временем, а вот в облаках всё время пропадет... Мой старенький Fujifilm FS4500 - файлы именует по порядку, а не по времени. И если с .jpg всё путём - есть всякие exif, то с .avi всё плохо.... Время ушло...
Каких то критичных данных не много и храню не там.
Никак не дойдут руки до проверки хранения метаданных у encfs и ecryptfs, нехочу пока влазить в процесс синхронизации, и так он затянулся.

Хранить в контейнерах на облаках нереально... Там просто rsync на подмонтированный davfs - легко кушает по 20Gb на корне.... Как я понял - любое изменене в файле - тащит его целиком сюда, меняет и вертает взад...

Сорри за очередное «выпадение». Воюю с облаками... Процесс Яндекс зеркала так придушил комп, что больше ничем и нельзя заняться...

Встаёт желание, как разживусь деньжатами - сделать тестдрайв Яндекс зеркала в применении к разным разделам. Сейчас не пойму что так душит. Сам ЯД или zfs? ЯД с 11 февраля у меня пытается утащить зеркало моего ЯД с сервера на вновь купленный локальный винт.

2Тб на ЯД - существенно больше 2Тб на HDD. Я тупанул, и денег сэкономил... Надо было взять 3Т винт, я же начал синкать 2Тб ЯДа на 2Тб винт от Тошибы... А эти грёбанные Терабайты у всех свои...
Где то это 2Миллиарда байт, Где то это 2 миллиона мегабайт, где то это 2000 гигабайт, а где то это четные 2 терабайта (2 в 40 степени). На 2000 винте от Тошибы - честных 1.8Тб. 250Гигов с ЯДа пришлось удалять, для того чтобы он влез на Тошибу.

Сейчас очередной виток синхронизации. Тупо с диска тащит по 15-30Mb/s и видимо считает контрольные суммы. На статусе 148Gb из 1.23Tb (11%) Celeron E3400@2.6GHz занят под завязку... Надеюсь хватит отавшихся свободных 2Гб, иначе опять что то удалять и ждать очередного витка синхронизации.

У ТСа и так проблемы посерьёзнее чем файлы на компьютере.

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

metastore is a tool to store the metadata of files/directories/links in a file tree to a separate file and to later compare and apply the stored metadata to said file tree. It was originally written as a supplement to git, which does not store all metadata, making it unsuitable for e.g. storing /etc in a repository. metastore can also be helpful if you want to create a tarball of a file tree and make sure that «everything» (e.g. xattrs, mtime, owner, group) is stored along with the files.

Спасибо, но я не так выразился... Мне хочется некой метафс, типа ecryptfs (Хотя может и она сработает) - которая показывает дату/время из своих полей, а не времени модификации файла.
Отдельные дату/время я храню в дереве дырок, приложении написанном местным форумчанином по моему ТЗ.

Вспомнился досовский descript.ion …

Уж тогда не descript.ion а ea data.sf

Но КМК решение в контейнеризации. Тарбол, образ диска, другое…

Не удобны контейнеры... Из них надо «вытаскивать» и не всегда это удобно/возможно.

А вообще никак не доберусь до encfs и ecryptfs - возможно где то это реализовано, а если нет то можно подумать над предложением авторам :)

ЗЫЖ Тамбовский волк тебе господин лол. Не нужно вот этого вот антиконституционного экстремисьму супротив дидовского равенства.

Я вот другого не пойму... Почему эти грёбанные облака не хранят оригинального mtime? Есть же ctime, и храните там время записи на облако....

Храните все в архивах.

да. или просто создать в облаке пустой файлик, на который накатить какую-нибудь ФС и монтировать\раздавать непосредственно её.

сейчас я бы сделал файл и смонтировал с -o loop или выставил бы как nbd, но не знаю как там с этим в сетевых хранилищах.

Облака это немного не сетевые хранилища...
Всякие NASы это по сути SAMBы... Они нормально отрабатывают хранение времени, да и доступ к контейнерам.
Но облака это отдельное черезжопие. У них же там своя архитектура и свои требования к безопасности, в итоге все они своё нутро показывают через webDAV или свои приложения, а там всё завязано на mtime а не ctime. И большие контейнеры тащатся на локальный диск чтобы поменять пару байт, а потом льются обратно...

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

Мне пока мыслится предложение авторам encfs и ecryptfs (если они это ещё не реализовали), в облаке будет всё храниться шифрованным и с родной метаинфой...

в tar их, а потом в облако

Это если использовать облако как бэкап. Но хочется и прозрачного доступа к файлам...

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

Мой старенький Fujifilm FS4500 - файлы именует по порядку, а не по времени.

Хм, может просто скриптом переносить нужные данные в имя файла? Никаких лишних сущностей.

создать в облаке пустой файлик, на который накатить какую-нибудь ФС

Век живи, век учись.

Мне хочется некой метафс, типа ecryptfs (Хотя может и она сработает) - которая показывает дату/время из своих полей, а не времени модификации файла.

Ага. То есть, что-то типа https://github.com/shabeer/catalog_file_system.

Но проект старый, и вряд ли сильно поможет. :)

Я вот другого не пойму… Почему эти грёбанные облака не хранят оригинального mtime? Есть же ctime, и храните там время записи на облако….

Nextcloud хранит исходное время модификации файла, проверил гуглодиск - тоже хранит…

Может, что то в настройках не так? Терять время файла - это баг, пользователи бы жаловались

Да, но modify у него как был так и остался.

Какой modify? ctime или mtime?
Увы... Облака на всё это кладут...
И УВЫ! Ни encfs ни eCryptfs не хранят атрибуты времени, хотя сначала кажется это так, как впрочем и у davFS. Пока не перемонтируешь ресурс - он показывает оригинальное время, но на облаке Мейла и Яндекса - файлы уже с временем записи в облако. Их можно сколько угодно раз менять на смонтированном davFS, но в облаке они не поменяются.

Может, что то в настройках не так? Терять время файла - это баг, пользователи бы жаловались

Пользователям НАСРАТЬ! Я один жаловался и в ЯД и в Мейл - сказали что всё так и ни чего менять не будут. Облако хранит ТОЛЬКО время записи в него... Хотя webDAV даёт иллюзию смены времени, пока не перемонтируешь облако.

создать в облаке пустой файлик, на который накатить какую-нибудь ФС

Век живи, век учись.

И обращаться к нему из оффтопика? Из под линукс возможно подключение лишь по webDAV, а он для замены пары байт в 10G контейнере по ощущениям тащит все 10Gb на локальный диск, меняет 2 байта и заливает 10Gb обратно... При этом Линукс дико тормозит...

Ни encfs ни eCryptfs не хранят атрибуты времени

https://www.cryfs.org/comparison
https://github.com/cryfs/cryfs

Хм, может просто скриптом переносить нужные данные в имя файла? Никаких лишних сущностей.

Этот вариант тоже рассматривается. Дажескрипт на ЛОРе уже нашел, но криво это... ПОЧЕМУ ОБЛАКО НЕ ХРАНИТ ОРИГИНАЛЬНОЕ ВРЕМЯ ФАЙЛА?
Это порнография а не облако.... Что мейл что ЯД...

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

Кто-то помнит на FTP о таких файлах как ls-lR ?

да. или просто создать в облаке пустой файлик, на который накатить какую-нибудь ФС и монтировать\раздавать непосредственно её.

1. Это технологически практически невозможно.
2. Такой вариант ты раздашь в ЕДИНСТВЕННОМ экземпляре, хотя может и есть чудо ФС позволяющие несколько раз смонтировать один раздел...

невозможно

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

Какой modify? ctime или mtime?

mtime

кстати, sqlfs? )

Ни encfs ни eCryptfs не хранят атрибуты времени

https://www.cryfs.org/comparison
https://github.com/cryfs/cryfs

СПАСИБО ЗА НАВОДКУ! На первый взгляд он сохраняет время.
А то encfs сказал:
Core ERROR . («Unknown») at «Secure/.encfs/RtTBNDerKfm,ee3q9VGC
/NU9we-/,Jw-0vVr63yLQI9»
eCryptFS какой то больно защищённый.... Чтобы смонтировтать надо ответить на несколько вопросов и если какой то ответ отличается о того какой был при создании - монтируется пустой каталог.... Это защита такая?

Впрочем и с cryfs пока не могу совладать. Он легко пставился, в Debian BookWorm надо просто #apt install cryfs
Создал, настроил, записал...
Подмонтировал ЯД с другого компьютера.... Шифрованная папка есть но пуста... минут 40 уже... Сейчас буду размонтировать и перемонтировать... Всё же технология не взлетает для распределенного доступа.

А то encfs сказал:

Core ERROR . («Unknown») at «Secure/.encfs/RtTBNDerKfm,ee3q9VGC
/NU9we-/,Jw-0vVr63yLQI9»
Наврал, это не encfs, а yandex-disk на шифрованный каталог encfs.

ты(тут конкретно лицо утверждающее что без шифрконтейнерезации помещение данных в облако проблема большая(во всяком случае) чем не полнота помещённых в это облако данных (в частности некоторых логированных самой фс свойств ) пользуешься естественным языком в создании которого не принимал участие ==> у тя проблемы посерьёзнее чем указывать другим о больших проблемах которые их не беспокоят

sizeof(бюджет)?