Уникально идентифицировать директории и файлы

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

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

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

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

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

Обсуди доступ по VPN, ну а чтобы не утекали пароли сделай авторизацию по электронным ключам, возможно самодельным.
Ну и ограничь вход конкретными подсетями или IP индивидуальными для каждого сотрудника.

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

У ТС психологические проблемы и он выдумавает под них костыль.

А может он просто скор набивает.

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

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

возможно такая файловая система и правда существует которая сличает не только идентификаторы

Есть подозрение, что ZFS и Btrfs так работают, на уровне блоков дедуплицируя данные.

мне больше видится вариант с версированием, раскручивать версии проще, чем сличать содержимое.

мне больше видится вариант с версированием

Я постеснялся советовать ТСу версионирование, потому что это прям на поверхности, как организационное решение. Ну или ещё как пример S3 Object Storage, где файл только по метаданным идентифицируется.

Я думал, что он эти варианты рассматривал.

и при изменении имени директории не исправлять все ссылки

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

Я постеснялся советовать ТСу версионирование

И правильно, правильно что не посоветовал. Потому что как только появляется система управлением версиями, так сразу появляется требование интеграции её клиентской части в каждое приложение, работающее с документами.

Это требование невыполнимо на практике.

и точно не уровня файловой системы

Но это неточно. Потому что бывают разные протоколы (типа WebDAV), поддерживающие версионирование, и файловые системы тоже бывают поддерживающие версионирование.

Object Storage рассматривали?

Да я так понял ТС надо локально, ну и судя по этому только обжект сторадж и выжил https://en.wikipedia.org/wiki/Versioning_file_system и кажется очевидно по какой причине.

По inode, через find как-то можно искать, но при перемещении файла inode меняется. По чек-суммам можно сделать, но здесь возрастает время поиска.

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

не меняется инод при перемещении, но меняется если пересоздать файл.

NILFS2

А что это такое? Точнее, какой пакет надо устанавливать? В википедии нет русской страницы, аналогичной https://en.wikipedia.org/wiki/Object_storage

Как так, не знать про S3 и реализации? И что вы всё «какой пакет устанавливать»? Техника это потом, сначала концепцию подобрать.

Про S3, например смотрите здесь https://github.com/awesome-selfhosted/awesome-selfhosted#file-transfer---object-storage--file-servers

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

не меняется инод при перемещении

В пределах блочного устройства, подозреваю.
Тогда все просто: find -inum в руки и вперед.

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

В файловой системе у любого объекта есть только один универсальный идентификатор это его имя, любая файловая система имеет средства для изменения имени объекта, есть такие идентификаторы, как inode, но они будут меняться на разных файловых системах, так что живите в реальном мире и пишите ваш PDF, чтобы он учитывал реалии этого мира

И вот мне не повезло

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

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

люди, которые файлы переименовывают как это делают?

Они прямо задались целью делать это максимально возможным количеством способов. Потому что они самые умные и лучше знают, в каком ПО им удобнее работать.

Почитал, я почитал этот трэд и вот какие соображения сообразились.

Абстрактную задачу надо решать абстрактными методами.

Поэтому абстракция №1.

Какое-то количество людей делает рабочие документы. doc1, doc2,... docX. (с произвольными именами и в произвольных дирах раскиданные)

Абстракция №2.

Какое-то другое количество других людей делает pdf. pdf1, pdf2,... pdfX. (с произвольными именами, но в одной и то же дире /server/pdf/...)

Внутри этих pdf есть ссылки на файлы из первой абстракции. И эти ссылки рабочие и правильные.

Бамбалейла №1.

Какие-то половозрелые индивиды с пубертатными замашками и зайчатками мозга начинают удалять файлы из абстракции №1. Тогда в абстракции №2 ссылки внутри pdf становятся битыми.

Бамбалейла №2.

Файлы в абстракции №1 остаются на месте, но переименованы. Ссылки внутри pdf - битые.

Бамбалейла №3.

Файлы в абстракции №1 перенесены в другие диры. Ссылки внутри pdf - битые.

Бамбалейла №4.

Файлы с типичными названиями типа «Отчет 2022» перезаписываются разными людьми своими версиями своих отчётов. А чё таково? Мои же файлы важнее каких-то там других. В этой войне правок википедиков побеждают не самые правильные, а самые упорото упорные. Ссылки внутри pdf - целые. Только вот они совсем-совсем неправильные.

Вывод:

При наличии запрета на административно-карательные и технически-запретительные методы воздействия на абстракцию №1 ты видишь именно такую ситуацию. Штатное возникновение коллизий вообще никак не разрешимых на уровне файловой системы (хоть с гуидами, хоть без).

Поэтому ты создаёшь новую абстракцию №3. СИСТЕМУ. Эта система является внешней и не является составной частью ни абстракции №1, ни абстракции №2. Эта система наблюдает за состоянием абстракции №1. И записывает в себя полный список всех файлов со всеми нужными реквизитами абстракции №1 с заданной периодичностью. Листинги файловой системы хранятся вечно.

При возникновении расхождения в листингах между соседними точками отсчёта система принимает решение «что делать». Например, ничего не делать, если файлы из абстракции №1 не участвуют в ссылках внутри абстракции №2.

Или система самостоятельно исправит битые ссылки внутри файлов из абстракции №2. А против файлов, в которых невозможно исправить ссылки, будут объявлены санкции и они будут посажены в карантин.

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

Всё так и есть, только 1 и 2 могут быть любыми и ссылаться друг на друга тоже (чтобы было веселее). Всё равно на предложенное решение это никак не влияет.

Другими словами у тебя написано что нужно:

1. следить
2. решать проблемы

Поэтому ты создаёшь новую абстракцию №3. СИСТЕМУ.

Так, предлагали и версионирование и s3 и организационно решать проблему. Что дальше советовать трэкер, сэд, crm, erp? )

ТС спросит, «а какой пакет ставить», получит ответ Odoo и на этом опять всё остановится.

Наши гениальные пользователи не будут разбираться ни с какой вашей ERP никогда. Всё должно быть невидимым, закопано под файловую систему, и в системные приложения (например открытие URL-ов).

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

Продублировать симлинками.

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

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

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

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

Неа, git понимает одинаково и git mv и просто mv. Я вообще не понял, зачем они эти команды в него вносили. При коммите он смотрит на хеши и если хеш удаленного файла совпадает с вновь созданным в другом месте, он понимает это как mv.

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

так то и мув в пределах одной файловой системы инод не меняет.

inode этот идентификатор.

Многие редакторы при редактировании файла сначала сохраняют новое содержимое в новый файл и потом переименовывают его затирая старый файл. В этом случае, очевидно, inode поменяется.

так и есть, если происходит пересоздание, а не просто перемещение тогда поменяется.

он их понимает скорее всего только в пределах подконтрольной гиту директории,

естественно. А как иначе? Остальное в коммитах не участвует. Собственно, и дедупликация и прочее, что смотрит в хеши в файловых системах работает только в рамках одной файловой системы или каталога с базой, если это что-то сверху, типа basckuppc, seafile или git.

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

А, про вендувс я совсем не подумал. Бессмысленная система, которую имхо никаким git не вылечить…

Может быть, действительно, для них и сделали.

Неа, git понимает одинаково и git mv и просто mv. Я вообще не понял, зачем они эти команды в него вносили. При коммите он смотрит на хеши и если хеш удаленного файла совпадает с вновь созданным в другом месте, он понимает это как mv.

По идее можно переместить файл, а потом его подредактировать. Если ide в фоне не отследит и не добавит файл, то и гит не сможет по хешу.

S3 Object Storage

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

Бессмысленная система, которую имхо никаким git не вылечить…

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

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

нет постоянных анонимных шар

minio вроде умеет в разные политики.

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

вроде пишут, что она не умеет xattr

Я не тебе отвечал.

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

Нет, в теории продвинутый ИИ с таким справится. Если ты способен такое написать — тебе прямая дорога в Google или Amazon.