Возможно ли оперировать файлом не через /path/to/file а по inode?

Для ковыряния некоторых ФС есть debugfs

mv в пределах фс так и делается. Сначала в новом каталоге делается link на файл, а потом в старом каталоге делается unlink

Про debugfs слышал, но что мне он в прикладном плане может дать пока не понял. И главная цель - не париться с именами и путями, оперировать через inodes.
А я даже запустить файл не могу.
!12345 - запуск команды из history по номеру. Вот ищу аналогичное применение для inodes.

А смысл то какой? Я вот не пойму.

Я как на одесский рынок пришёл) Хоть бы кто ответил не вопросом на вопрос. Смысл - меняются пути и имена файлов - так надо. Задолбало после во всех конфигах их перепрописывать заново каждый раз. Хочу обработчик ошибки в случае отсутствия файла - его обнаружение по Inode.

Можно по имени файла получить его хендл и идентификатор маунта. А потом, через какое-то время, может быть даже после перезагрузки, открыть файл не по имени, а по хендлу и идентификатору маунта. https://man7.org/linux/man-pages/man2/name_to_handle_at.2.html

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

не по имени, а по хендлу и идентификатору маунта.

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

Я конечно могу имея inode узнать по нему имя и возможно путь ``find . -inum 402808 -blablabla` а потом обратиться к файлу по вычисленному имени, но это уже не то.

Но мне кажется тебе проще сделать

Нет, я не знаю заранее, кто поменяет имя или путь. Кандидатов тысячи. На всех хардлинков не напасёшься и это лишняя сущность.

Кстати, а на венде в ntfs есть аналог Inodes?

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

Так, ответ мудрого еврея тут уже был, теперь дан ответ дзэн мудреца.

Странное - это имена и пути файлов в 2023 году, как единственный основной способ обращения к ним.

Я хочу обращаться к файлам по константам, а не переменным. Это норма, а не странность.

mv мальчик.jpg девочка.jpg

и всё (c) а был ли мальчик?™ Вот что странность.

Сформулирую ещё раз.

УМЕЕМ: Получить inode файла:

ls -i ~/look.txt | awk {'print $1'}

Показать текстовой файл ~/look.txt по его inode

find -inum 91918 -exec cat {} \;

Но на самом деле find сперва нужно его найти. Что может быть очень долго с кучей мусора в консоли.

ВОПРОС: как сделать тоже самое, только без find? В линуксе есть адекватный инструмент для доступа к inode?

В линуксе есть адекватный инструмент для доступа к inode?

Тут пишут что надо патчить ядро. Патч отклонили из-за проблем с безопасностью.

Наверно, только через финд, но он долго ищет и надо скрипты колхозить.

https://stackoverflow.com/questions/36092559/open-file-by-inode

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

inode одного и того же файла могут меняться при перемонтировании ФС, например в результате дефрагментации или изменения размера раздела.

Вас, кажется, Поттеринг покусал.

по константам, а не переменным

А это какие-то лучшие практики JavaScript

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

Я хочу обращаться к файлам по константам, а не переменным.

inode не константа.

Ну вот, поют сверчки. Выходит, что INODE в линуксе как чемодан без ручки.

Когда файлов тысячи это нереальный не вариант! Плюс если часть из файлов удаляется, как потом ещё искать хардлинки и их удалять, и помнить второй путь, где они лежат? Это лишние ненужные сущности и нереальный АДъ.

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

А причём тут он?

Ваша программа не может найти файл. Вы его переместили, а в программе нет контекстной замены по БД. Чито делать? Жуярить ручками все файлы, даже если их сотни. А в нормальной ОС, где inode не чемодан без ручки, можно мгновенно найти все утерянные файлы по inode, и выдать пользователю на подтверждение валидности.

Это я только один из многих прикладных пользовательских кейсов описал. Легион их. А кто покусал вас, я не знаю. Может почтальон Печкин. «У меня для вас файл есть, но без докУментапути и имени я вам его не выдам».

Если как-то (чем?) inode угрожает безопасности, нужен аналог. Файлам нужен внеИерархический идентификатор.

Тебе нужно content-addressable storage, а не игрища с инодами.

Почему мне это нужно? В рамках ОС средствами баша это доступно? Если нет, то концепцию на бутерброд не намажешь.

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

Ваша программа не может найти файл. Вы его переместили

Чё-то вспомнил рекламу складной удочки. Там основной посыл был, «Если вам ВДРУГ вздумалось порыбачить...» - типа, идёт чувак за хлебушком, и ВНЕЗАПНО вздумалось порыбачить...

Вот и с описанным кейсом то же.

В рамках ОС средствами баша это доступно?

Гитом пользуешься?

а ты случаем в wow на warmane не катаешь?

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

Наверное вы имеете в виду «программа не может найти файл, который она открывала в прошлый раз». Ну вот когда она его открывала в прошлый раз, она могла и хардлинк на него сделать. Например программа открывала файл с путём /home/user/videos/my-home-video.avi и сохранила в недавние с помощью хардлинка ~/.recent/home-user-videos-my--home--video.avi. В следующий раз программа читает оглавление каталога ~/.recent и говорит какие недавние файлы удалили (nlinks==1), какие переместили (nlinks==2, но отсутствует по оригинальному пути), и спрашивает что делать: восстановить/захоронить удалённые, разыскать переименованные, или просто почистить весь ~/.recent.

а можно поподбробнее о таком варианте развития событий рассказать ??

inode должна была бы быть внутренней кухней ядра/ФС, в том, что оно протекло наружу виноват Спольски, со своим законом о дырявых абстракциях.

rm file ; touch file

это тот же файл? нет да.

Возможно ли оперировать файлом не через /path/to/file а по inode? (комментарий)

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

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

В ОС, где inode не чемодан без ручки, я бы просто запустил простой скрипт, формирующий таблицу соответствий путей вида:

# inode path
34734 /path/to/filename

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

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

иногда. А что?

Я играю только на zx/c64/dendy/ps1. На современные игры жалко времени, годы как не играл. А к чему вопрос?

Бинго! Первый, кто догадался, для чего это может быть нужно. Но Вы далеко не первый, кто не хочет или не мможет понять или прочитать выше, что Возможно ли оперировать файлом не через /path/to/file а по inode? (комментарий)

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

Вы опять какую-то ерунду. Как можно сделать rm file до того, как его touch? И главное, к чему это сказано - непонятно.

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

Это и делается при дефрагментации или изменении размера раздела. Но детали зависят от конкретной ФС.

Ник увидел там. Твой Ник такой, запоминающийся.

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

Скриншот покажьте, аватара должна отличаться)
Першая мысль: Какая-то ска мой уникальный ник с314здила.
Вторая: Хотя нет, хик дофига. И это обычное японское слово…

В игре, зарубежная гильдия, так что…

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

Мне часто приходилось переименовывать старый конфиг (для бекапа или подсмотреть) и писать новый. Если бы программа искала конфиг по inode, а не по имени, то она продолжила бы ходить по старому.

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

Плюс иноды есть не на всех ФС. На каком-нибудь FAT их нету (заголовок файла пересоздается при переносе из каталога в каталог, плюс нету сквозной нумерации файлов, а только внутри каталога). Что делать ядру?

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

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

все хардлинки имеют идентичные права uid gid и т.д. ибо эти параметры прописываются в inode
https://www.kernel.org/doc/html/latest/filesystems/ext4/inodes.html
i_mode содержит права на файл
i_uid i_gid соответственно владельца и группу.

как я понимаю…