vi 在創建新文件之前創建交換文件
這是一個奇怪的問題。為新文件創建交換文件。所以，我的目錄是空的，沒有文件存在，然後當
vi test.txt我收到交換文件消息時。它看起來像vi創建 .swp 文件作為故障轉儲並向我顯示恢復文件消息。nfs setting: netapp-3240:/vol/vol0/test /testing nfs rsize=8192,wsize=8192,timeo=14,intr 0 0 [user@rh-test]cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.9 (Tikanga) [user@rh-test]ls -la total 8 drwx------ 2 root root 4096 Nov 8 15:35 . drwx------ 9 root root 4096 Nov 8 13:59 .. /testing [user@rh-test]vi test.txt E325: ATTENTION Found a swap file by the name ".test.txt.swp" owned by: rahmed dated: Fri Nov 8 15:30:06 2013 [cannot be read] While opening file "test.txt" dated: Fri Nov 8 15:29:59 2013 (1) Another program may be editing the same file. If this is the case, be careful not to end up with two different instances of the same file when making changes. Quit, or continue with caution. (2) An edit session for this file crashed. If this is the case, use ":recover" or "vim -r test.txt" to recover the changes (see ":help recovery"). If you did this already, delete the swap file ".test.txt.swp" to avoid this message. Swap file ".test.txt.swp" already exists! [O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort: [user@rh-test]ls -la total 8 drwx------ 2 root root 4096 Nov 8 15:39 . drwx------ 9 root root 4096 Nov 8 13:59 .. -rwx------ 1 user sysadmins 0 Nov 8 15:39 .test.txt.swo -rwx------ 1 user sysadmins 0 Nov 8 15:39 .test.txt.swp當然，如果我通過 echo 創建文件，則沒有交換文件。
[user@rh-test]echo "this is test file" > test.txt /testing [user@rh-test]ls -la total 8 drwx------ 2 root root 4096 Nov 8 15:29 . drwx------ 9 root root 4096 Nov 8 13:59 .. -rwx------ 1 user sysadmins 18 Nov 8 15:29 test.txt的輸出
:set dir是directory=.,~/tmp,/var/tmp,/tmp請注意，這只發生在這個 nfs mount 上
/test。同一系統上的其他本地和 nfs 掛載沒有此問題。掛載選項：
netapp-3240:/vol/vol0/test on /testing type nfs (rw,rsize=8192,wsize=8192,timeo=14,intr,addr=10.200.23.22)更改為 nfsvers=2 後，它開始工作
nfsvers=2 或 nfsvers=3 — 指定要使用的 NFS 協議版本。這對於執行多個 NFS 伺服器的主機很有用。如果沒有指定版本，NFS 使用核心和 mount 命令支持的最高版本。NFSv4 不支持此選項，不應使用此選項。
netapp-3240-2:/vol/vol1/testing on /test type nfs (rw,rsize=16384,wsize=16384,intr,nfsvers=2,addr=10.200.23.22)**
解決：
此問題與未正確設置的 NetApp 選項有關。為了解決這個問題，我們必須在 NetApp 上的“options cifs.ntfs_ignore_unix_security_ops on”上設置此選項。**
電子郵件執行緒
我從 2008 年發現這個執行緒，似乎過時了，但聽起來和你的問題完全一樣。這似乎是專門針對 NetApp 的。我注意到，在您的輸出中，伺服器被命名為
netapp-3240我認為是 NetApp 設備。該執行緒的標題為：奇怪的行為，NTFS qtree 上的 Linux 和 NFS。具體來說，提到了您遇到的相同症狀。
問題概要
摘抄
我目前正在評估的 FAS3040 文件管理器出現一些奇怪的行為。我有一個由 NFS 和 CIFS 導出的 NTFS 樣式的 qtree。Debian Linux 客戶端看到與 open() 和 stat64() 系統呼叫有關的奇怪行為。簡而言之，“vim”的這個 strace 輸出擷取了它：
uname({sys="Linux", node="acheron", ...}) = 0 stat64("ffff", 0xbfb4d030) = -1 ENOENT (No such file or directory) stat64("ffff", 0xbfb4d0b0) = -1 ENOENT (No such file or directory) access("ffff", W_OK) = -1 ENOENT (No such file or directory) open("ffff", O_RDONLY) = -1 ENOENT (No such file or directory) readlink("ffff", 0xbfb4c7cc, 1023) = -1 ENOENT (No such file or directory) open(".ffff.swp", O_RDONLY) = -1 ENOENT (No such file or directory) open(".ffff.swp", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) stat64(".ffff.swp", {st_mode=S_IFREG|0777, st_size=0, ...}) = 0請注意，open(O_RDWR…) 呼叫因 EACCES 失敗；但以下 stat64() 呼叫成功。儘管報告了 open() 呼叫失敗，但仍在磁碟上創建了文件 ffff.swp。
使用“vim”編輯文件時可以看到此行為，並導致有關交換文件存在的錯誤消息（由於交換文件正在創建，即使 open() 返回值暗示它不存在）。
在 Tru64 NFS 客戶端上嘗試相同的“vim”命令，可以看到正確的行為：open(O_RDWR…) 成功並返回文件句柄。
nfsver=2
有這個建議解決了這個問題。除了確認您遇到了與該執行緒正在解決的相同問題外，您沒有其他原因可以嘗試它。
摘抄
但是在您的電子郵件之後，我嘗試了 vers=2 並且問題消失了（使用 TCP 和 UDP），這確實很有趣。儘管這裡有瘋狂大小的文件和文件系統，但 NFSv3 是非常可取的。
在你的出口上做這樣的事情：
rw,intr,tcp,nfsvers=2,rsize=16384,wsize=16384,addr=192.168.1.1cifs.ntfs_ignore_… 選項
線上程中還有一件事要嘗試：
在文件管理器上將選項 cifs.ntfs_ignore_unix_security_ops 設置為 on 可能會起作用。
還有什麼？
除了這些事情之外，還有其他一些事情要嘗試，但我無法確認，因為我無法訪問要嘗試的 NetApp 文件管理器。您也可以瀏覽一些 NetApp 網站的 URL，但我也無權確認這些內容。
無論如何，我強烈建議您閱讀此執行緒，因為它似乎是您奇怪的
vim說法的主要候選人，它有一個 .swp 文件，而實際上它沒有。