Some problem about renaming a File or Directory - Unix

This is a discussion on Some problem about renaming a File or Directory - Unix ; Hi, I am reading AUP. In section 3.3.2 about renaming a file and directory, I am a little confused why it is so complicate. The prototype of rename is int rename ( const char* oldpath, const char* newpath ).In the ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Some problem about renaming a File or Directory

  1. Some problem about renaming a File or Directory

    Hi,

    I am reading AUP. In section 3.3.2 about renaming a file and directory,
    I am a little confused why it is so complicate. The prototype of rename
    is int rename ( const char* oldpath, const char* newpath ).In the book,
    the rename proceeds as following:

    1. If newpath exists, remove it with unlink or rmdir.
    2. link( oldpath, newpath ), even if oldpath is a directory.
    3. Remove oldpath with unlink or rmdir.

    My problem is how about to directly access the corresponding entry in
    its belonging directory and then rename it. Seems it is doable.

    Best,
    Tony

  2. Re: Some problem about renaming a File or Directory

    Tony, Zhang wrote:
    > I am reading AUP. In section 3.3.2 about renaming a file and directory,
    > I am a little confused why it is so complicate. The prototype of rename
    > is int rename ( const char* oldpath, const char* newpath ).In the book,
    > the rename proceeds as following:
    >
    > 1. If newpath exists, remove it with unlink or rmdir.
    > 2. link( oldpath, newpath ), even if oldpath is a directory.
    > 3. Remove oldpath with unlink or rmdir.
    >
    > My problem is how about to directly access the corresponding entry in
    > its belonging directory and then rename it. Seems it is doable.


    Are you talking about the special case where the source and
    destination directories are the same? It probably results in
    cleaner code not to handle this special case differently than
    the others (where the file may be moved to another directory
    within the same filesystem). I think the simplicity of doing
    both those things the same way is the reason why there is way,
    that I know of, to open the directory and change the name
    directly within it.

    If you're concerned about efficiency, it might be more efficient
    to chdir() to the directory first, especially if you are renaming
    multiple files. However, it would not be as general since it is
    possible to have the permissions to rename files but not have the
    permissions to chdir() into the directory containing those same
    files.

    - Logan

  3. Re: Some problem about renaming a File or Directory

    "Tony, Zhang" writes:

    > Hi,
    >
    > I am reading AUP. In section 3.3.2 about renaming a file and
    > directory, I am a little confused why it is so complicate. The
    > prototype of rename is int rename ( const char* oldpath, const char*
    > newpath ).In the book, the rename proceeds as following:
    >
    > 1. If newpath exists, remove it with unlink or rmdir.
    > 2. link( oldpath, newpath ), even if oldpath is a directory.
    > 3. Remove oldpath with unlink or rmdir.
    >
    > My problem is how about to directly access the corresponding entry in
    > its belonging directory and then rename it. Seems it is doable.


    The rename() function cannot be implemented like that in userspace
    since the rename is required by POSIX to be atomic:

    If the link named by the new argument exists, it shall be removed
    and old renamed to new. In this case, a link named new shall remain
    visible to other processes throughout the renaming operation and
    refer either to the file referred to by new or old before the
    operation began.

    Either the requirements have been made more strict since the book was
    written, or that breakdown was only intended as loose explanation, not
    actual implementation. Whichever the case, rename() must be
    implemented as a system call on POSIX system, and your question is
    thus moot.

    --
    Måns Rullgård
    mans@mansr.com

  4. Re: Some problem about renaming a File or Directory

    In article ,
    Måns Rullgård wrote:

    > "Tony, Zhang" writes:
    >
    > > Hi,
    > >
    > > I am reading AUP. In section 3.3.2 about renaming a file and
    > > directory, I am a little confused why it is so complicate. The
    > > prototype of rename is int rename ( const char* oldpath, const char*
    > > newpath ).In the book, the rename proceeds as following:
    > >
    > > 1. If newpath exists, remove it with unlink or rmdir.
    > > 2. link( oldpath, newpath ), even if oldpath is a directory.
    > > 3. Remove oldpath with unlink or rmdir.
    > >
    > > My problem is how about to directly access the corresponding entry in
    > > its belonging directory and then rename it. Seems it is doable.

    >
    > The rename() function cannot be implemented like that in userspace
    > since the rename is required by POSIX to be atomic:
    >
    > If the link named by the new argument exists, it shall be removed
    > and old renamed to new. In this case, a link named new shall remain
    > visible to other processes throughout the renaming operation and
    > refer either to the file referred to by new or old before the
    > operation began.
    >
    > Either the requirements have been made more strict since the book was
    > written, or that breakdown was only intended as loose explanation, not
    > actual implementation. Whichever the case, rename() must be
    > implemented as a system call on POSIX system, and your question is
    > thus moot.


    Before the rename() system call was created (in an early BSD release, I
    think), this was essentially how the mv command worked. I think had to
    be setuid so that it could link and unlink directories (mkdir and rmdir
    were similar). But it wasn't atomic in those days, and the setuid
    allowed some security holes, which is why the system calls were created.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***

+ Reply to Thread