Por que renomear um arquivo com o comando mv altera a data e hora de “mudança” de um inode?

Question

Um arquivo hello.c é renomeado para hi.c. Como mostra a saída do comando stat, o carimbo de hora [change] foi alterado. geralmente é alterado quando o inode do arquivo foi modificado. Por que renomear com o comando mv altera o conteúdo do inode e, na verdade, qual atributo é modificado?

xyz@linuxPC:~/Documents$ stat hello.c
 File: ‘hello.c’
 Size: 568          Blocks: 8          IO Block: 4096   regular file
Device: 809h/2057d  Inode: 261889      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/ xyz)   Gid: ( 1000/ xyz)
Access: 2015-04-22 19:54:34.889330399 +0530
Modify: 2015-04-22 19:54:34.241330427 +0530
Change: 2015-06-21 15:46:45.365465523 +0530
Birth: -
xyz@linuxPC:~/Documents$ mv hello.c hi.c
xyz@linuxPC:~/Documents$ stat hi.c 
 File: ‘hi.c’
 Size: 568          Blocks: 8          IO Block: 4096   regular file
Device: 809h/2057d  Inode: 261889      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/ xyz)   Gid: ( 1000/ xyz)
Access: 2015-04-22 19:54:34.889330399 +0530
Modify: 2015-04-22 19:54:34.241330427 +0530
Change: 2015-06-21 15:48:23.361469822 +0530
Birth: -

    

Answer 1

Eu fiquei intrigado e fiz uma pequena escavação. No começo eu pensei que fosse algum tipo de efeito colateral, por exemplo o nó recebe 2 links e, em seguida, o link original é excluído e o ctime é mais um acidente do que uma ação deliberada.

Caso não esteja claro para alguém, o arquivo é representado por um inode que tem nada relacionado ao nome. O inode "sabe" quantos nomes obteve graças ao contador de hardlink, mas não tem pistas sobre quais são esses nomes ou em quais diretórios eles residem.

Com isso, vamos dar uma olhada no POSIX ( link ):

Some implementations mark for update the st_ctime field of renamed files and some do not. Applications which make use of the st_ctime field may behave differently with respect to renamed files unless they are designed to allow for either behavior.

E exemplo de implementação ( link ):

/*
 * We always want to hit the ctime on the source inode.
 *
 * This isn't strictly required by the standards since the source
 * inode isn't really being changed, but old unix file systems did
 * it and some incremental backup programs won't work without it.
 */
xfs_trans_ichgtime(tp, src_ip, XFS_ICHGTIME_CHG);

Então lá.

    

Answer 2

Há muito, muito tempo atrás, o comando

mv oldpath newpath

foi implementado dentro de mv.c as

link(oldpath, newpath);
unlink(newpath);

Agora temos uma chamada de sistema

rename(oldpath, newpath);

mas aparentemente ainda funciona da mesma maneira, dentro do kernel. Esta é uma conjectura da minha parte, mas é baseado no fato de que um dos modos de falha para renomear (2) é

EMLINK

oldpath already has the maximum number of links to it, or ...

e com base nos dados experimentais que você relatou (e isso eu confirmei no meu próprio sistema).

E então ...

Quando oldpath é vinculado a newpath , a contagem de links do inode aumenta em um. Quando oldpath é desvinculado, a contagem de links do inode é reduzida em um. Portanto, o inode é alterado (mesmo que seja imediatamente alterado de volta para o que era antes).

P.S. É interessante notar que o documento POSIX lista o EMLINK como um possível código de retorno de erro, mas não para o caso de renomeação de arquivo para arquivo.