Jim Meyering: Any thoughts about this issue? From: "Jeffrey D. Carter" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: mv sometimes removes destination after failure Date: Mon, 20 Dec 2004 09:52:47 -0500
Package: fileutils Version: 4.1-10 kernel version 2.4.26 I was testing various error scenarios when an NFS server gets rebooted. When this happens, the DRC (duplicate request cache) usually isn't preserved, and non-idempotent operations can fail incorrectly. This is the test scenario: hard-mount NFS. cd top touch file mkdir directory mv -v file directory/file This is run from several clients while the server is rebooted. What you would expect is that if an NFSPROC3_RENAME reply is dropped just as the server goes down that it will reply with an NFSERR3_NOENT when the retransmitted request is processed after the boot. This is exactly what is seen in the ethereal trace: RENAME top-fh file directory-fh file xid = 1 [timeout] RENAME top-fh file directory-fh file xid = 1 retransmit RENAME top-fh file directory-fh file xid = 1 retransmit RENAME top-fh file directory-fh file xid = 1 retransmit RENAME top-fh file directory-fh file xid = 1 retransmit [repeats] RENAME reply xid = 1 ENOENT Perfect. So the rename syscall fails, but the file was renamed anyway. So top/file is gone, top/directory/file exists, and is the old file. So a script could conceivably deal with this through some kind of defensive programming. But then it gets odd. The mv command reports: 'file' and 'directory/file' are the same file and then it REMOVES directory/file! Now, BOTH the old location and the new location are gone, and the file is lost. Looking at the source, it is not at all obvious to me how mv can ever remove the destination, and under what conditions this is considered reasonable. Jeff Carter [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
