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

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

Мы имеем признаки:

• идиот один и тот же
• имеется последовательность из удаления и появления нового

Основываясь на таких признаках тренируем нейросеть…

Профит.

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

Рискну предположить, что руководство хочет получить от тебя систему документооборота с версионированием, только чтобы ничего не пришлось покупать, а людям ничего не пришлось осваивать, так? Тут надо просто объяснить, что задача невыполнимая, и предложить три варианта: 1) они таки раскошеливаются, хотя бы на обучение; 2) они отказываются от своей затеи; 3) ты увольняешься.

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

Бесплатно, это в смысле на опенсорсе.

Если система документооборота и версионирования встроится в работу прикладных компьютерных программ таким образом, что её не будет заметно, то пользователям не надо будет переучиваться.

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

на уровне файловой системы запрети все действия с файлами и директориями кроме создания (директории и файла) и изменения содержимого файла.

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

всё.

где использоваться будет столь чудная архитектура?

на вскидку можно посоветовать создавать в директории файл с метаданными, типа desktop.ini или .folder

и написать скрипт, для поиска нужной директории/файла

где использоваться будет столь чудная архитектура?

Ну, он просто хочет систему документооборота без системы документооборота. А что бы оно как-то там само, волшебно. И какая оказия бы не случилась, а оно само опа — и «вот». А вот так вот --- «вот». И даже вот так вот — «ВОООТ». И всё само, само...

к имени файла добавить UUID, по нему и искать файл:

${document-viewer} $(locate $UUID)

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

потому что потом директорию переименуют и всё

Не переименовывайте.

Это ты хакер-одиночка. А при работе в организации кто-то занимается одними делами (придумывает имена директориям, а потом понимает что накосячил, придумывает по-новой и переименовывает), а кто-то другой должен обеспечить, чтобы всё продолжало работать.

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

Ты не там ищешь решения проблемы, нужно доносить мысль до руководства, желательно в письменном виде, описав, что из-за вот таких вот переименовываний (с примером) вся документация летит в звезду. И если вы хотите, чтобы было норм — делайте вот так.

И дальше все косяки ссылать на эту письмо.

А твой путь решения проблемы лишь добавит тебе геммороя потом, поверь. Да и нет его, наверное.

Запихни всё в git

Хард-линки помогут, но не на 100%

Как ни крути все костыли ведут тебя к системе документооборота.

В итоге ведь тебе нужны сами файлы, а не директории? Имён у файла может больше одного. Это называется жёсткие ссылки. Напиши скрипт или программу, которая будет для каждого нового файла создавать жёсткую ссылку, т.е. привязывать тот же inode в другую директорию. Например, создаёт пользователь /home/user/отчёт.pdf, а твоя программа это через inotify отслеживает и делает hard link вида /home/.all-files/some-id-123. ID генертруешь, как тебе вздумается. При этом отчёт.pdf можно переименовать как угодно. Соответственно в другой документ надо вставлять путь до .all-files.

в другой документ надо вставлять путь до .all-files

Думаю, что с этим будут проблемы:
1) какой софт этим будет заниматься?
2) даже если это будет пресловутая «Система документоооборота», то как она узнает, какая фиксированная ссылка (фиксированный путь) соответствует файлу?
3) что будет происходить с файлами, редактируемыми «на стороне»?

И всё само, само…

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

у каждого файла был свой уникальный идентификатор

incron и его заставь переименовывать файлы скриптиком с доавлением в имя date (c cекундами) и $$.

Если всё так как в описано в треде, то единственно верное решение проблемы ТС описано в ст. 80 ТК РФ.

Либо не страдать фигнёй, внедрять СЭД и приучать пользователей к правилу «не загрузил в СЭД - значит файла нет и никогда не было»

Либо не использовать файлы вообще, а хранить информацию в подходящей для этого БД.

Либо, как сказал ls-h - хардлинки + на клиент пользователям команда «получить постоянный путь к файлу». В проводник встроить, кстати, вообще не проблема. Но, как уже неоднократно сказали, проблему «удалил файл и заменил новым извне» это не решит.

Нельзя выдать куче обезьян острые ножи, чтобы они фрукты могли резать, но так, чтобы ни одна обезьяна ни сама не порезалась, ни других не поранила. А задача выставляется как поставленная именно с подобными требованиями. Тут или сверху пытаются совокупиться с мозгом сотрудника, либо наоборот. А значит ст. 80 ТК РФ, пока не случилась ст. 81.

получить постоянный путь к файлу

Смотря куда, в документы какого формата, ТС вставляет эти ссылки. Можно написать ещё одну программку, которая будет так же через inotify следить и заменять одни пути на другие.

Но вообще сама задача это какая-то непонятная мура.

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

тогда %тс% стоит купить систему документооборота под свои требования и тех.поддержку. самое правильное и эффективное прикладное решение.

Ваша проблема (всех советчиков покупки системы документооборота) в том, что вы не можете сформулировать, какие же проблемы эта система решит. Причём таким образом, что это нельзя реализовать приказом по фирме.

Если редактировать документы на сервере, сломается возможность заверения документа ЭП.

Но вообще сама задача это какая-то непонятная мура.

Это да. Вообще похоже на дипломную работу «учителя информатики» в пед. вузе, когда ни преподаватель толком не разбирается в вопросе, ни студент. Но что-то такое, похожее на «волшебную кнопку» сделать хочется и «возможно же, надо просто всё предусмотреть».

Нам и формулировать не надо. Какие вопросы закрывает та или иная СЭД давно сформулировано.

А вот ты уже сколько времени не можешь сформулировать задачу. Описываешь не её, и даже не её сами симптомы проблемы, а свои фантазии на тему «как эти симптомы лечить». Может там лечить уже нечего, болезнь уже в терминальной стадии?

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

Пока же, из того что ты описал, ты пытаешься сделать СЭД без СЭД.

дополню: %тс% не хочет даже думать/писать четкое тз :)

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

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

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

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

И вот теперь я должен перебрать сто систем, и убедиться, что все они не решают нерешаемую задачу. Это вместо того, чтобы чётко описать, почему она нерешаемая.

Вы же настаиваете, что она решаемая, и её могут решить СЭД. Не могут!

начни с себя: Внятно опиши задачу

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

«Сама спросила, сама ответила, сама и обиделась».

Я тебе говорил, что она нерешаемая? Нет. Я говорил, что ты вместо исходной задачи вылил сюда поток сознания. Давай сюда задачу.

Подход «определить задачу, подобрать инструмент для её решения и решить» - единственно верный из работающих.

Есть ещё «определить задачу и в процессе решения перебирать инструменты», но он дорогой.

А подход в котором первым делом не идёт определение задачи - по определению кривой и используется только когда цель не результат, а ИБД.

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

«Чтобы продать что-нибудь ненужное, нужно сначала купить что-нибудь ненужное, а у нас денег нет». Ты сначала задачу чётко опиши, потом будешь рассказывать почему она нерешаемая.

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

просто внятнее надо описывать

Они, эксперты, именно этим и занимаются. Но проблема в том, что разные люди понимают разные слова по-разному.

Введение «хардлинков» фактически перекладывает роль финального судьи здравого смысла на админа. Но он же не эксперт!

Насрали Вам тут вам в топик

Решение: incron