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

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

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

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

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

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

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

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

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

В общем, сформировался примерно такой образ:  

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

Где взять, как сформировать? Если есть уже готовые решения, то делитесь ссылочками, но интересует и самому слегка разобраться ) 

> Записывать ИД первой / последней строкой в файл можно конечно, но это такое себе. Можно с таким же успехом просто давать файлам уникальные имена, это не интересно. 

  

<https://habr.com/post/46935/> 

 Полагаю, что если строить свою ИС (инф. сист.) поверх прослойки, работающей посредством FUSE, то все упростится.  

В своей нижележащей ФС можно назначать файлам UUID. Файл - это некий объект, с которым может быть ассоциирована такая служебная информация, как имя файла или URI, в общем виде, которые подвержены частым изменениям. Набор таких объектов хранить в некой СУБД (допустим, SQLite).  

При монтировании хранилища посредством FUSE в какую-нибудь директорию наружу будут видны как обычные файлы. При изменении имени файла меняется только служебная информация об объекте в хранилище. Хранилище может быть как локальное, так и удаленное. При удалении файла-документа в хранилище можно пометить объект как подлежащий утилизации или же просто удалению. При изменении версии файла-документа меняется содержимое объекта в хранилище. В служебной информации (meta data) можно также хранить хэш от содержимого. 

> Уникальный идентификатор, * не изменяющийся при * изменении его содержимого

  

вам [сюда](http://lurkmore.to/%D0%92%D0%B7%D0%B0%D0%B8%D0%BC%D0%BE%D0%B8%D1%81%D0%BA%D0%BB%D1%8E%D1%87%D0%B0%D1%8E%D1%89%D0%B8%D0%B5_%D0%BF%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D1%8B)   
  

по проблеме- sha 256 от первого гигабайта со всеми вытекающими  

либо имя файла  

либо (ваш случай) - 42 

 Готового решения под ваши запросы нет, и в ближайшее время не предвидится.  

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

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

Если создать несколько копий одного файла - на какой из них будет указывать ваша суперссылка?  

Если переписать файлы на флешку с fat32 а затем обратно?  

Передать по сети?  
  

Вообще для решения этой проблемы придумали [URI](https://ru.wikipedia.org/wiki/URI), но работает, опять-же, не везде и не всегда. 

 Поскольку разные люди в разных местах пишут на одну и ту же тему, я сокращу изначальный текст:  

В линуксе есть жёсткие ссылки. Независимо от действий с файлом жёсткая ссылка продолжает на него ссылаться. Если я правильно понимаю, то жёсткая ссылка привязывается к inode, который ведёт себя несколько непредсказуемо. Например, на домашнем ПК при изменении файла жёсткая ссылка работает корректно:  
![5bab0f07e77e1308813230.png](https://habrastorage.org/webt/5b/ab/0f/5bab0f07e77e1308813230.png)  

но на рабочем ПК почему-то изменения файла приводят к изменению инод и жёсткая ссылка уже отображает неверное содержимое файла:  
![5bab27721fc44800482405.png](https://habrastorage.org/webt/5b/ab/27/5bab27721fc44800482405.png)  

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

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

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