[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BUG in mv(1) over NFS as root

From: Steven Augart
Subject: Re: BUG in mv(1) over NFS as root
Date: Thu, 2 Oct 2003 16:35:13 -0400


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 <address@hidden>
Sent by: address@hidden

10/02/2003 02:13 AM

        To:        address@hidden
        Subject:        BUG in mv(1) over NFS as root

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 Rosenfeld
Fritz Haber Research Center
Hebrew University
Phone:  (972) 2 658-5270
Fax:    (972) 2 651-3742
E-mail: address@hidden

Bug-coreutils mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]