Чи можливо перейменувати файл або каталог за допомогою inode?


10

Я змінив / home каталог на інший розділ і не зміг отримати доступ до файлів з нього. Щось мені вдалося вирішити з цього питання - Як ви отримуєте доступ до вмісту попереднього кріплення після переходу на інший розділ? .

У випадку, якщо я раніше зазначив inode каталогу, чи зможу я використати його поодинці для перейменування каталогу?

Відповіді:


6

Ви можете перейменувати файл (каталог або будь-що інше), використовуючи лише знання про вкладку, використовуючи find, але якщо (a) файлова система, що містить її, не встановлена, або якщо (b) є інша файлова система, встановлена ​​над не порожнім каталогом, який містить файл, який вас цікавить, файл просто не доступний вашій системі. У випадку (а) вам потрібно змонтувати файлову систему, перш ніж робити що-небудь до вмісту, включаючи перейменування, а у випадку (б) вам потрібно відключити файлову систему, встановлену "вгорі" каталогу, що містить файл, який потрібно перейменувати. Схоже, ви запитуєте про випадок (b).

Якщо я вас правильно зрозумів, ви намагаєтесь зробити доступ до старої /homeкаталоги (яка знаходиться на вашому кореневому розділі), використовуючи новий розділ, встановлений на /home. Якщо ви цього хочете, зробіть наступне:

Закрийте всі файли та вийдіть із системи. Потім увійдіть як root(використовуйте для цього віртуальний термінал - натисніть Ctrl-Alt-F2). Виконайте наступне:

umount /home
mv /home /home-old
mkdir /home
mount -a
ls /home
ls /home-old

Якщо все добре, вийдіть із системи та увійдіть назад як самі, і все має бути добре.

До речі, команда перейменувати файл з використанням лише знань про його inode (якщо припустити, що файл знаходиться у поточному каталозі):

find . -maxdepth 1 -inum 123456789 -exec mv {} mynewname \;

Де 123456789, звичайно, номер inode. (Зверніть увагу, що findвизначає ім'я файлу та його шлях і передає цю інформацію до нього mv; взагалі немає способу перейменувати файл, не залучаючи існуюче ім'я файлу, але якщо ви просто не знаєте імені файлу, це цілком простий.)


Чи може команда mv перейменувати безпосередньо на основі inode? Я припускаю, що команда find повертає ім'я файлу у звичайному текстовому вигляді.
vfclists

@vfclists: Ні, mvжоден спосіб не прийме вставки .
Wildcard

6

У типовій файловій системі Unix переміщення файлу на основі inode взагалі неможливо. Причина полягає в тому, що перейменування файлу означає видалення його запису з каталогу, який містить його, та створення каталогу в іншому місці. Але inode не містить вказівника на запис каталогу, він містить лише (покажчики на) метадані файлу (часові позначки, дозволи тощо) та вміст файлу.

Для файлу з декількома жорсткими посиланнями, яке з них ви б перейменували? У inode недостатньо інформації.

Для каталогу, у деяких файлових системах, можна було б діяти, даючи лише вклад:

  1. Прочитайте вміст каталогу, який, безумовно, доступний з inode.
  2. Знайдіть запис каталогу для ... Це вказує на батьківський каталог.
  3. У батьківському каталозі шукайте запис каталогу з правильним номером вводу.

Однак це робить кілька припущень:

  • Що робити, якщо для одного ідентичного елемента є кілька записів? Насправді це не проблема: це навряд чи трапиться на практиці, оскільки більшість варіантів Unix забороняють явні жорсткі посилання на каталоги.
  • Чи ..існує в першу чергу? Це залежить від типу файлової системи. Деякі файлові системи мають чіткий запис для ..; для інших ці записи підроблені драйвером файлової системи. Якщо ..його немає, такий підхід принципово неможливий.
  • Навіть якщо файлова система містить ..посилання, є ще один камінь спотикання, який може бути не очевидним: крок 1 може бути можливий всередині ядра, але для нього немає інтерфейсу. У багатьох варіантах unix немає інтерфейсу, який дозволяє відкривати файл через його inode, оскільки це дозволить обійти дозволи. Наприклад, файл з дозволами rwxr-xr-x(тобто читається у всьому світі), який знаходиться в каталозі з дозволами rwx------(тобто доступний лише його власникові), не доступний нікому, крім власнику каталогу. Це неможливо визначити лише в inode - файл може бути фактично доступний через інше жорстке посилання!

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

Єдиний практичний спосіб діяти на файл з урахуванням його inode - це спочатку знайти шлях, наприклад, з find -inum, а потім використовувати шлях для дії. Це не допоможе у вашій ситуації, коли файл затінений точкою кріплення. Немає портативного способу доступу до файлів, затінених точкою кріплення; в Linux, як ви виявили, ви можете використовувати кріплення для прив’язки.


-1

Дякую. Це було найбільш корисно. Це дозволяє мені змінити громіздкі імена для стенограми відеофайлів, які я завантажив з YouTube, на більш лаконічні, але все ще значущі імена файлів. Наприклад:

you-get -O 20191129_tucker https://www.youtube.com/watch?v=cyCpkwX9Wvs

... дає мені файли:

20191129_tucker.webm; та "Збереження Такер Карлсон сьогодні вночі 11-29-19 FULL- Breaking Fox News 29 листопада 2019.en.srt"

Я вважаю це недоліком інакше дуже корисного ви отримаєте.

Я можу змінити ім'я другого файлу так:

$ ls -il "Збереження Такер Карлсон сьогодні вночі 11-29-19 FULL- Breaking Fox News 29 листопада 2019.en.srt"

... це дає мені список файлів із його номером inode на самому початку:

13902671 -rw-r - r-- 1 Джеймс Джеймс 55793998 30 листопада 18:44 Збереження Такер Карлсон сьогодні вночі 11-29-19 FULL- Breaking Fox News 29 листопада 2019.en.srt

... тоді я бігаю:

mvi 13902671 20191129_tucker.srt

Мій сценарій оболонки mvi bash:

#!/bin/bash
inodeNumber=$1
newFileName=$2
find . -maxdepth 1 -inum $inodeNumber -exec mv {} $newFileName \;

Це не додає будь-якої нової інформації, крім вищезазначеної. Крім того, ваш mviсценарій використовує змінені без змін котирування, а це означає, що він вийде з ладу, якщо будь-який з аргументів, наданих сценарію, містить символи пробілу (або, можливо, також, коли вони містять символи, що поширюються).
Кусалаланда
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.