淺談Linux下mv和cp命令的區別
我之前在項目中遇到一個很奇怪的問題，對於inotify監視一個文件的時候，發現有些時候inotify有些時候會“失效”。後來我就沒辦法，去監視文件所在的目錄。看下面的，
#!/bin/bash
src=/tmp/test/test.txt # directory to monitor
/usr/local/bin/inotifywait -rmq -e modify $src | while read event
do
echo "hello"
done
奇怪的現象就是如果我 mv test.txt /tmp/test/test.txt 的時候，發現 inotify 竟然沒有除非，但是我無意中發現 cp test.txt /tmp/test/test.txt 的時候，強制覆蓋了，發現 inotity 就觸發了。我這兩天上OS的時候，突然間想到了原因。可能是 inode 節點的問題，看下面
上面注意 inode 節點的變化，cp 的時候是真正意義上的內容copy，對於 inode 節點卻是不會變化的mv 的時候是把目標文件直接刪除了（inode 刪除了），新的文件其實已經不是以前的文件了，只是名字一樣而已。這樣就可以解釋 inotify 的“異常”了，mv 之後原文件的 inode 節點都已經刪除了，inotify是跑在內存裡面的，它依然在讀取之前的 inode 節點，但是已經刪除了，這導致了inotify掛了。
inode 是ＯＳ在磁盤上尋找文件一個必不可少的，下面可以再來看個例子．
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>
int main(int argc, char const *argv[])
{
/* code */
int fd = open("./1.txt",O_RDWR);
char buff[256] = {'\0'};
if (fd < 0)
{
printf("error open file\n");
exit(1);
}
int i = 0;
while(1)
{
sprintf(buff,"%d %s\n",i,"hello");
write(fd,buff,strlen(buff)+1);
printf("%s\n",buff );
++i;
sleep(1);
}
close(fd);
return 0;
}
上面的程序就是向1.txt寫文件，前提是 1.txt 是存在的，真正的原因就是沒有 inode 節點，也就沒有了對應的磁盤文件．現在假設有了 1.txt 這時候程序 1s 鐘寫一次文件，我們 mv 1.txt 2.txt ，這時候會發現程序竟然向 2.txt 裡面寫數據了，原因就是程序是在內存裡面，對於1.txt 的抽象就是文件描述符號，write只認識它，write 通過寫描述符，描述符去找相應的 inode 節點，然後寫磁盤．mv 了之後 inode 節點還是存在的，也就是寫 2.txt 了．