É possível renomear um arquivo ou diretório usando o inode?


Respostas:


6

Você pode renomear um arquivo (diretório ou qualquer outra coisa) usando apenas o conhecimento do inode find, mas se (a) o sistema de arquivos que o contém não estiver montado, ou se (b) houver outro sistema de arquivos montado em um diretório não vazio que contenha o arquivo em que você está interessado, o arquivo simplesmente não está acessível pelo seu sistema. No caso (a), é necessário montar o sistema de arquivos antes de fazer qualquer coisa no conteúdo, incluindo renomear; no caso (b), é necessário desmontar o sistema de arquivos montado "por cima" do diretório que contém o arquivo arquivo que você deseja renomear. Parece que você está perguntando sobre o caso (b).

Se o entendi corretamente, você está tentando tornar seu /homediretório antigo (localizado na partição raiz) acessível, enquanto ainda usa a nova partição montada em /home. Se é isso que você deseja, faça o seguinte:

Feche todos os arquivos e efetue logout. Em seguida, efetue login como root(use um terminal virtual para isso - pressione Ctrl-Alt-F2) Execute o seguinte:

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

Se tudo estiver bem, efetue logout e efetue login novamente como você e tudo ficará bem.

Aliás, o comando para renomear um arquivo usando apenas o conhecimento de seu inode (assumindo que o arquivo esteja no diretório atual) é:

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

Onde 123456789está o número do inode, é claro. (Observe que finddetermina o nome do arquivo e seu caminho e passa essas informações para mv; não há nenhuma maneira de renomear um arquivo sem envolver o nome do arquivo existente, mas se você não conhece o nome do arquivo, é bastante simples.)


O comando mv pode renomear diretamente com base no inode? Suponho que o comando find retorne o nome do arquivo em sua forma textual normal.
usar o seguinte comando

@vfclists: Não, mvnão aceita inodes de forma alguma.
Wildcard

6

Em um sistema de arquivos típico do Unix, é estruturalmente impossível, em geral, mover um arquivo com base no inode. O motivo é que renomear um arquivo significa remover sua entrada do diretório que o contém e criar um diretório em outro lugar. Mas o inode não contém um ponteiro para a entrada do diretório, apenas contém (ponteiros para) os metadados do arquivo (registros de data e hora, permissões etc.) e o conteúdo do arquivo.

Para um arquivo com vários links físicos, qual deles você renomeará? O inode não é informação suficiente.

Para um diretório, em alguns sistemas de arquivos, seria possível agir apenas com o inode:

  1. Leia o conteúdo do diretório, que é definitivamente acessível a partir do inode.
  2. Localize a entrada de diretório para ... Isso aponta para o diretório pai.
  3. No diretório pai, procure uma entrada de diretório com o número de inode correto.

Isso faz várias suposições, no entanto:

  • E se houver várias entradas para o mesmo inode? Na verdade, isso não é um problema: isso quase nunca acontece na prática, pois a maioria das variantes do unix proíbe links físicos explícitos para diretórios.
  • Existe ..em primeiro lugar? Isso depende do tipo de sistema de arquivos. Alguns sistemas de arquivos têm uma entrada explícita para ..; para outros, essas entradas são falsificadas pelo driver do sistema de arquivos. Se ..não existir, essa abordagem é fundamentalmente impossível.
  • Mesmo que o sistema de arquivos inclua ..links, há outro obstáculo que pode não ser óbvio: a etapa 1 pode ser possível dentro do kernel, mas não há interface para isso. Muitas variantes do unix não possuem interface que permita a abertura de um arquivo por meio do seu inode, porque isso ignoraria as permissões. Por exemplo, um arquivo com permissões rwxr-xr-x(ou seja, legível pelo mundo) localizado em um diretório com permissões rwx------(ou seja, acessível apenas ao proprietário) não é acessível a ninguém, exceto ao proprietário do diretório. Isso não pode ser determinado apenas a partir do inode - o arquivo pode estar acessível através de outro link físico!

O resultado é que não, não é possível fazer nada, incluindo renomear, com um arquivo apenas com seu inode. Você precisa ter um caminho para o arquivo.

A única maneira prática de agir em um arquivo, dado seu inode, é primeiro encontrar um caminho, por exemplo find -inum, com e depois usá-lo para agir. Isso não ajuda na sua situação, onde o arquivo é sombreado por um ponto de montagem. Não há uma maneira portátil de acessar arquivos sombreados por um ponto de montagem; no Linux, como você descobriu, você pode usar uma montagem de ligação.


-1

Obrigado. Isso tem sido muito útil. Ele permite que eu altere nomes pesados ​​para transcrição de arquivos de vídeo que baixei do YouTube para nomes de arquivos mais sucintos, mas significativos. Por exemplo:

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

... me dá os arquivos:

20191129_tucker.webm; e "Saving Tucker Carlson Tonight 11-29-19 FULL- Breaking Fox News 29 de novembro de 2019.en.srt"

Considero que isso é uma desvantagem do que de outra forma seria muito útil.

Eu posso alterar o segundo nome do arquivo da seguinte maneira:

$ ls -il "Saving Tucker Carlson Tonight 11-29-19 FULL- Breaking Fox News 29 de novembro de 2019.en.srt"

... isso me fornece a lista de arquivos com seu número de inode logo no início:

13902671 -rw-r - r-- 1 james james 55793998 30 de novembro às 18:44 Saving Tucker Carlson Tonight 11-29-19 FULL- Breaking Fox News 29 de novembro de 2019.en.srt

... então eu corro:

mvi 13902671 20191129_tucker.srt

Meu script mvi bash shell é:

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

Isso não adiciona nenhuma informação nova além do que foi mencionado anteriormente. Além disso, seu mviscript usa variáveis ​​não citadas, o que significa que ele falhará se algum dos argumentos fornecidos ao script contiver caracteres de espaço em branco (ou potencialmente também quando eles contiverem caracteres brilhantes).
Kusalananda
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.