淺談Linux下mv和cp命令的區別--轉載

我以前在項目中遇到一個很奇怪的問題，對於inotify監視一個文件的時候，發現有些時候inotify有些時候會

「失效」。後來我就沒辦法，去監視文件所在的目錄。看下面的，

[python] view plaincopyprint?
  #!/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 是ＯＳ在磁盤上尋找文件一個必不可少的，下面能夠再來看個例子．

[python] view plaincopyprint?
  #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 了．