This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 172233 - rename(2) onto an empty directory fails on NFS file systems
rename(2) onto an empty directory fails on NFS file systems
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Brian Brock
:
Depends On:
Blocks: 168424
  Show dependency treegraph
 
Reported: 2005-11-01 14:38 EST by Neil Horman
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHSA-2006-0144
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-15 11:49:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Neil Horman 2005-11-01 14:38:59 EST
+++ This bug was initially created as a clone of Bug #172081 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921
Red Hat/1.0.7-1.4.1 Firefox/1.0.7

Description of problem:
Any application using the rename(2) system call to rename onto an empty
directory will receive EBUSY if doing this on an NFS mount point.  If both
the source and targets of the rename are directories, and the target is
empty, the rename should succeed.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
see description.
  

Actual Results:  rename() system call returns EBUSY

Expected Results:  rename() should succeed if two directories are involved, and
receive an error
(EISDIR or ENOTDIR) only if renaming a file to a directory or vice versa.

Additional info:

this problem should be investigated in RHEL 3 as well.

commit 6fe43f9e3701f7a9f2be151a5e6cfe94b87e92f9 in the master 2.6 git
repository contains a fix for this problem.

-- Additional comment from nhorman@redhat.com on 2005-11-01 06:49 EST --
chuck, can you provide the exact command please?  This command:
rename \/mnt\/ \/mnt\/test\/ /mnt/neil.txt

works fine if test is a local directory but return EXDEV if test is NFS mounted.
 Since you said it returns EBUSY, I'd like to be sure that we're seeing the same
problem before I look at the fix.  Thanks!

-- Additional comment from cel@netapp.com on 2005-11-01 09:16 EST --
hi guys-

the problem is with the rename(2) system call.  write a test program that
creates an arbitrary empty directory in NFS, then uses rename(2) to rename
another NFS directory onto it.  the expected result is that the empty directory
will be replaced.

-- Additional comment from nhorman@redhat.com on 2005-11-01 10:03 EST --
The rename utility directly uses the rename syscall, but to illustrate:
=======================================================
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char **argv)
{
        char *from = argv[1];
        char *to = argv[2];

        if (rename(from,to)<0)
                perror("unable to rename");

        return 0;
}
===========================================================
if test is a local directory, this works fine, but if the destination is an nfs
mount point:
[root@x120-8678-2 mnt]# ./a.out ./neil.txt /mnt/test/neil.txt
unable to rename: Invalid cross-device link
[root@x120-8678-2 mnt]# uname -a
Linux x120-8678-2.gsslab.rdu.redhat.com 2.6.9-22.9.ELsmp #1 SMP Fri Oct 28
18:38:46 EDT 2005 i686 i686 i386 GNU/Linux

Given that the man page indicates that EXDEV is the required return code from
the use of the rename syscall accross filesystems, this seems to be operating
correctly.  I can't seem to get it to produce an EBUSY.  If you could provide
your exact test case, I'd certainly appreciate it.  Thanks

-- Additional comment from cel@netapp.com on 2005-11-01 11:44 EST --
hi neil-

i'm not trying to rename across file systems.

1.  create two subdirectories of a directory on an NFS mount.  call them
subdirectory "A" and subdirectory "B".  they both reside in the same parent
directory, and thus they are both contained in the same file system.

2.  use your program to rename A as B.

rename(2) will return EBUSY.

-- Additional comment from nhorman@redhat.com on 2005-11-01 13:49 EST --
Created an attachment (id=120617)
patch to massage upstream commit to RHEL4 kernel 

Sorry, Chuck.  I've reproduced the problem now, and verified the fix on the
latest RHEL4 kernel.
Comment 1 Ernie Petrides 2005-11-01 16:35:27 EST
I don't believe renaming mount points should be allowed.  The EBUSY
error is appropriate, and that's what I get with an ext3 mount point,
so why should an nfs mount point be treated differently?

I'm tentatively closing this as NOTABUG.

SteveD, if you disagree, please reopen this.  Thanks.
Comment 2 Neil Horman 2005-11-01 16:40:39 EST
Its not mount points that we're trying to rename, its subdirectories beneath
mount points.  In the testcase above.  test is the NFS mount point, and A and B
are subdirectories beneath the mount point.
Comment 3 Ernie Petrides 2005-11-01 16:52:51 EST
Ah, thanks for clarifying this, Neil.  In the initial comment of this
bugzilla, the following line:

  "... if doing this on an NFS mount point."

should read:

  " ... if doing this under an NFS mount point."

Reopened and assigned to Neil, who has already posted a patch for
internal review today.
Comment 5 Ernie Petrides 2005-11-28 17:59:36 EST
A fix for this problem has just been committed to the RHEL3 U7
patch pool this evening (in kernel version 2.4.21-37.11.EL).
Comment 8 Andrius Benokraitis 2006-01-09 10:57:18 EST
This fix has been committed in the RHEL3 U7 beta.

Action: Netapp, please test and provide feedback to RH ASAP.
Comment 10 Red Hat Bugzilla 2006-03-15 11:49:35 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0144.html

Note You need to log in before you can comment on or make changes to this bug.