LINUX.ORG.RU
ФорумAdmin

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

 , , ,


1

5

Этот вопрос возник когда начал использовать облака. На данный момент Яндекс и МейлРу - хранят лишь время записи файла в облако, а не его оригинальное время модификации. С другими атрибутами тоже не уверен что всё в порядке, а желательно ещё сохранять владельца и права доступа.
Изначально вопрос «встал» после потери оригинальных времён медиафайлов, но лично мне эта ситуация не нравится в целом. Мало ли что я решу сохранить... А потом и разбирайся какая из копий новее...
Вот помнится в OS/2 для fat был файл: «ea data.sf» в котором хранилось всё, вплоть до длинного имени файла... Хотя конечно не знаю всей подноготной того что хранилось в том файле...

★★★

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

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

anonymous
()

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

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

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)

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

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

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

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)

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.

dataman ★★★★★
()

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

antech
()
Ответ на: комментарий от anc

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

antech
()
Последнее исправление: antech (всего исправлений: 1)
Ответ на: комментарий от t184256

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

Нет у меня ни каких проблем. Взял по акции 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Гб, иначе опять что то удалять и ждать очередного витка синхронизации.

n0mad ★★★
() автор топика
Ответ на: комментарий от einhander

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

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

n0mad ★★★
() автор топика
Ответ на: комментарий от dataman

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 (Хотя может и она сработает) - которая показывает дату/время из своих полей, а не времени модификации файла.
Отдельные дату/время я храню в дереве дырок, приложении написанном местным форумчанином по моему ТЗ.

n0mad ★★★
() автор топика
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

n0mad ★★★
() автор топика
Ответ на: комментарий от sergej

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

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

n0mad ★★★
() автор топика
Ответ на: комментарий от antech

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

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

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

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

t184256 ★★★★★
()
Ответ на: комментарий от n0mad

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

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

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

dataman ★★★★★
()
Ответ на: комментарий от n0mad

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

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

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

Aster
()
Ответ на: комментарий от anc

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

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

n0mad ★★★
() автор топика
Ответ на: комментарий от Aster

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

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

n0mad ★★★
() автор топика
Ответ на: комментарий от zzplex

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

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

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

n0mad ★★★
() автор топика
Ответ на: комментарий от ddidwyll

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

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

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

n0mad ★★★
() автор топика
Ответ на: комментарий от flant

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

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

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

невозможно

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

flant ★★★★
()
Ответ на: комментарий от dataman

Ни 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 уже... Сейчас буду размонтировать и перемонтировать... Всё же технология не взлетает для распределенного доступа.

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 4)
Ответ на: комментарий от t184256

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

qulinxao3 ★★
()