Tom,
What you describe is the behavior that I would expect. mv(1) has never
been atomic when moving across filesystems; it's only atomic when renaming
a single inode within a single filesystem.
Even in the single i-node on one filesystem case it's not perfectly atomic,
at least under the Linux kernel. The rename(2) manual page states:
"However, when overwriting there will probably be a window
in which both oldpath and newpath refer to the file being renamed."
This non-atomic behavior is explicitly documented in the coreutils.info info pages.
I don't see why you consider it a bug.
AND, that limited degree of atomicity has only been available since Berkeley
BSD 4.2 Unix, which introduced an atomic rename() call; until then, even in the single
i-node case, mv had been implemented by a combination of link() and unlink().
More to the point, I don't see what improvement to the behavior you propose.
Moving any entity across filesystems is inherently non-atomic under Unix
filesystem semantics.
Maybe you're looking for something like a transactional
database where one can perform a group of operations as a single
transaction that either entirely succeeds or entirely fails? That would
be an interesting design for a filesystem, but it is not achievable with the current
set of customary GNU/Linux system calls. (And two such file systems wouldn't
be able to co-operate across NFS anyway; they'd need a new networked
filesystem protocol that could support the idea of transactions, just as you'd need
to extend the system call interface to support transactions.)
--Steve Augart
| Tom Rosenfeld <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 10/02/2003 02:13 AM |
To: [EMAIL PROTECTED] cc: Subject: BUG in mv(1) over NFS as root |
Hi,
I believe I have found a bug in mv(1). The version is:
mv (coreutils) 4.5.3
When logged in as root and trying to mv a files from an NFS mounted directory where root dos NOT have permission to remove files since the dir was not exported with the "no_root_squash" option, if you try to mv(1) a file, it will 1st copy the file succesfully before getting an error on the unlink. Thus mv(1) is not atomic!
Have you seen this before?
-tom
--
Tom Rosenfeld
Fritz Haber Research Center
Hebrew University
Phone: (972) 2 658-5270
Fax: (972) 2 651-3742
E-mail: [EMAIL PROTECTED]
_______________________________________________
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
_______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
