☰

mv 명령을 사용하여 파일 이름을 바꾸면 inode의 "변경된" 날짜와 시간이 변경되는 이유는 무엇입니까?

tag-icon • tag-icon rename mv inode
mv 명령을 사용하여 파일 이름을 바꾸면 inode의 "변경된" 날짜와 시간이 변경되는 이유는 무엇입니까?

hello.c 파일의 이름은 hi.c로 변경됩니다. stat 명령의 출력에 표시된 것처럼 [change] 타임스탬프가 변경되었습니다. 일반적으로 파일의 inode가 수정되면 해당 아이노드도 변경됩니다. mv 명령으로 이름을 바꾸면 inode의 내용이 변경되고 실제로 수정되는 속성은 무엇입니까?

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: -

답변1

저도 관심이 생겨서 좀 찾아봤습니다. 처음에는 노드가 링크 2개를 얻은 후 원래 링크가 삭제되고 ctime이 의도적인 작업이라기보다는 사고에 가까운 일종의 부작용인 줄 알았습니다.

누구인지 확실하지 않은 경우 파일은 다음을 포함하는 inode로 표시됩니다.아무것도 없다이름에 관한 것입니다. inode는 하드 링크 카운터로 인해 얻은 이름의 수를 "알고" 있지만 해당 이름이 무엇인지 또는 해당 이름이 어느 디렉토리에 있는지에 대한 단서는 없습니다.

그럼 POSIX(http://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html):

일부 구현에서는 이름이 바뀐 파일을 업데이트하기 위해 st_ctime 필드를 표시하고 일부는 그렇지 않습니다. st_ctime 필드를 사용하는 애플리케이션은 두 동작을 모두 허용하도록 설계되지 않은 경우 이름이 변경된 파일과 다르게 동작할 수 있습니다.

및 구현 예(http://lxr.free-electrons.com/source/fs/xfs/xfs_inode.c#L2985):

/*
 * 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);

그게 다야.

답변2

오랜만에 주문

기세오래된 길 새로운 길

내부적으로는 다음 mv.c과 같이 구현됩니다.

협회(오래된 길,새로운 길);
연결 해제(새로운 길);

이제 시스템 호출이 있습니다.

이름 바꾸기 (오래된 길,새로운 길);

하지만 분명히 커널 내부에서는 여전히 같은 방식으로 작동합니다. 이것은 내 추측이지만 실패 모드 중 하나가이름 바꾸기(2)예

EMLINK

    오래된 길이미 최대 링크 수에 도달했거나...

그리고 귀하가 보고한 실험 데이터(그리고 제가 자체 시스템에서 확인한 데이터)를 기반으로 합니다.

그래서...

언제오래된 길에 연결되어 있습니다새로운 길, inode의 링크 수가 1 증가합니다. 언제오래된 길연결이 해제되면 inode의 링크 수가 1씩 감소합니다. 따라서 인덱스 노드가 변경됩니다(즉시 이전 상태로 다시 변경되더라도).

PS 흥미롭게도 POSIX 문서에는 EMLINK가 가능한 오류 반환 코드로 나열되어 있지만아니요파일 간 이름 바꾸기의 경우.

답변3

파일의 inode에는 아무것도 변경되지 않았으므로 이상적으로는 이름을 바꿀 때 ctime을 변경해서는 안 됩니다. 그러나 이는 파일에 대한 내용이 변경되었음을 백업 프로그램에 알리기 위해 파일을 강조 표시하는 편리한 방법입니다. 따라서 백업 절차에서는 "ctime이 마지막 백업 시간보다 최신입니다"를 확인하는 것만으로도 충분합니다.모두마지막 백업 이후 변경된 모든 파일입니다.

관련 정보