melodyn
@melodyn
Лучше нативная смерть, чем фреймворковая жизнь.

Возможно ли получить уникальный идентификатор файла?

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

Как я себе это представлял: при создании файла появляется возможность установить некую "метедату" или получить выданный системой идентификатор (ИД), который остаётся к нему привязан в течение всего "срока жизни". При формировании ссылок, я указываю ИД, а по окончании редактирования, например, перед пушем в репозиторий, запускаю скрипт, который просматривает файлы по ИД и устанавливает на них корректные ссылки в тексте основного документа.

Потратил сегодня много времени на гуглёжку, но не смог найти подходящего решения этой задачи, потому что всё свелось к inode и UUID.

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

UUID выглядит, как отличная альтернатива уникальной идентификации, однако, я так и не нашёл способа увидеть UUID конкретных файлов.

Подумал, что, возможно, смогу устанавливать некие пользовательские метаданные (а-ля data-attributes в HTML), но оказалось, что это очень ограниченная область и далеко не все инструменты могут работать с метаданными. Дополнительная сложность в том, что скрипт автоматизации хотелось написать на знакомом мне ЯП -- JS или PHP, но в документации последнего я так же не нашёл никаких способов помечать файлы некими уникальными идентификаторами.

Записывать ИД первой / последней строкой в файл можно конечно, но это такое себе. Можно с таким же успехом просто давать файлам уникальные имена, это не интересно. Из обходных путей - повесить демона, который будет отслеживать изменения в реальном времени, но он будет работать только в том случае, если человек развернул виртуалку, а для редактирования документов этого могут и не делать. Можно что-то прикрутить к гиту, чтобы на него повесить эту задачу, но опять же нужно знать что и как. Да и я не верю, что моя хотелка уникальная, всё это уже должно было быть решено сто раз.

Ещё пробовал жёсткие / символические ссылки, но при перемещении файла жёсткая ссылка начинает выдавать при чтении информацию из прошлой версии. Похоже на некое кэширование, не знаю, имеет ли смысл с этим бороться.

В общем, сформировался примерно такой образ:
Уникальный идентификатор, независящий от файловой системы, записанный на том уровне, откуда его возможно получить без танцев с бубнами, но и не на "видном месте", не изменяющийся при перемещении, переименовании файла и изменении его содержимого. Желательно, чтобы не требовал активного демона.

Где взять, как сформировать? Если есть уже готовые решения, то делитесь ссылочками, но интересует и самому слегка разобраться )
  • Вопрос задан
  • 942 просмотра
Решения вопроса 1
Taraflex
@Taraflex
Ищу работу. Контакты в профиле.
Записывать ИД первой / последней строкой в файл можно конечно, но это такое себе. Можно с таким же успехом просто давать файлам уникальные имена, это не интересно.

https://habr.com/post/46935/
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
2ord
@2ord
продвинутый чайник
Полагаю, что если строить свою ИС (инф. сист.) поверх прослойки, работающей посредством FUSE, то все упростится.
В своей нижележащей ФС можно назначать файлам UUID. Файл - это некий объект, с которым может быть ассоциирована такая служебная информация, как имя файла или URI, в общем виде, которые подвержены частым изменениям. Набор таких объектов хранить в некой СУБД (допустим, SQLite).
При монтировании хранилища посредством FUSE в какую-нибудь директорию наружу будут видны как обычные файлы. При изменении имени файла меняется только служебная информация об объекте в хранилище. Хранилище может быть как локальное, так и удаленное. При удалении файла-документа в хранилище можно пометить объект как подлежащий утилизации или же просто удалению. При изменении версии файла-документа меняется содержимое объекта в хранилище. В служебной информации (meta data) можно также хранить хэш от содержимого.
Ответ написан
dimonchik2013
@dimonchik2013
;)
Уникальный идентификатор, * не изменяющийся при * изменении его содержимого

вам сюда

по проблеме- sha 256 от первого гигабайта со всеми вытекающими
либо имя файла
либо (ваш случай) - 42
Ответ написан
Stalker_RED
@Stalker_RED
Готового решения под ваши запросы нет, и в ближайшее время не предвидится.
Сейчас есть множество файловых систем, которые не сохранят ваши супер-метки, и вся красивая задумка разрушится.

Для разминки можете представить что будет, если файл заархивировать, а затем распаковать.
Если создать несколько копий одного файла - на какой из них будет указывать ваша суперссылка?
Если переписать файлы на флешку с fat32 а затем обратно?
Передать по сети?

Вообще для решения этой проблемы придумали URI, но работает, опять-же, не везде и не всегда.
Ответ написан
melodyn
@melodyn Автор вопроса
Лучше нативная смерть, чем фреймворковая жизнь.
Поскольку разные люди в разных местах пишут на одну и ту же тему, я сокращу изначальный текст:
В линуксе есть жёсткие ссылки. Независимо от действий с файлом жёсткая ссылка продолжает на него ссылаться. Если я правильно понимаю, то жёсткая ссылка привязывается к inode, который ведёт себя несколько непредсказуемо. Например, на домашнем ПК при изменении файла жёсткая ссылка работает корректно:
5bab0f07e77e1308813230.png
но на рабочем ПК почему-то изменения файла приводят к изменению инод и жёсткая ссылка уже отображает неверное содержимое файла:
5bab27721fc44800482405.png
Видимо, связано с тем, что в случае с виртуалкой, система работает с файлами иначе, опираясь на файловую систему родительской машины.

Если у меня получится обеспечить поведение жёсткой ссылки независимо от местонахождения, то это позволит создать, например, каталог links, помещать туда жёсткие ссылки под уникальными именами, в коде указывать ссылку по типу [следующий файл](#my_awesome_hard_link) и задача решена.

Поэтому говорить о том, что это никому не нужно, не существует в природе или "чё ты придумал такое, лол", честно говоря, такое себе.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы