Your message dated Sat, 8 May 2010 08:02:51 +0200 (CEST)
with message-id <[email protected]>
and subject line Package fileutils has been removed from Debian
has caused the Debian Bug report #286493,
regarding mv sometimes removes destination after failure
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
286493: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286493
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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]
--- End Message ---
--- Begin Message ---
Version: 4.1.11-3+rm
You filed the bug http://bugs.debian.org/286493 in Debian BTS
against the package fileutils. I'm closing it at *unstable*, but it will
remain open for older distributions.
I was unable to find a bug that explains the reason for its removal,
but it appears to have been superceded by coreutils (which is an
essential package) on Mon, 30 Sep 2002 12:24:37 -0400.
I have decided not forward these bugs to coreutils, since a lot
could have been changed in these 8 years. If your issue is still
reproducible or still valid, do not hesitate to reopen and reassign
it or reply to this email.
Don't hesitate to reply to this mail if you have any question.
Thank you for your contribution to Debian.
--
Niels Thykier
--- End Message ---
