Re: [9fans] mv on directory - Plan9

This is a discussion on Re: [9fans] mv on directory - Plan9 ; > I know that. It's a copy, not move. Looking at mv.c, I believe anything that's not a rename (ie move within a directory) is a copy, then a hardremove. Mv(1) says the same thing. > I just can't see ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: [9fans] mv on directory

  1. Re: [9fans] mv on directory

    > I know that. It's a copy, not move.

    Looking at mv.c, I believe anything that's not a rename (ie move
    within a directory) is a copy, then a hardremove. Mv(1) says the same
    thing.


    > I just can't see any reason why to mention anything about any bug. I
    > didn't do that.
    >
    >

    I wrote that because of this message:

    http://groups.google.com/group/comp....thread/thread/
    cfa65300a62de30f

    from which I assumed you were extending the list you began there, and
    because I support your bug-list idea generally, but *not* as a list
    of places where, as I wrote before, "behavior deviates from the
    similarly-named command in lunix." It's just boring.

    > mkdir dirB
    > dircp dirA dirB
    > rm -r dirA


    It seems like if you made that an rc(1) script and bound it over /bin/
    mv, you'd have the desired behavior. No risk would be introduced to
    the system, whether or not anyone (aside from the documentation, that
    is) relies on mv(1) having the semantics of a wstat.

    Given that even if mv(1) agreed to move a directory into another
    directory, it would do so as a copy followed by a remove, I don't
    understand what benefit there would be in changing mv. It seems like
    you're essentially just calling dircp+rm -r by a different name,
    which is so easy to do with name spaces.

    All that said, it's not like I've never cursed a directory that
    wouldn't mv for me in Plan 9 -- so if someone had an answer for Rob's
    question: "What should mv do to a tree that resides on multiple file
    servers?", it could be interesting to discuss. I don't think arguing
    from rm -r is a good tact, though, because of the differing risk
    levels between a failed delete and a failed move. One might afford
    convenience in the former, and eschew it in the latter.

    -Josh



  2. Re: [9fans] mv on directory

    On Nov 1, 2008, at 9:30 AM, Josh Wood wrote:
    > All that said, it's not like I've never cursed a directory that
    > wouldn't mv for me in Plan 9 -- so if someone had an answer for
    > Rob's question: "What should mv do to a tree that resides on
    > multiple file servers?", it could be interesting to discuss. I don't
    > think arguing from rm -r is a good tact, though, because of the
    > differing risk levels between a failed delete and a failed move. One
    > might afford convenience in the former, and eschew it in the latter.


    That's a very good point. UNIX in general does guarantee certain
    things about rename of the
    subdirectories within the same FS, but the price they pay in the
    kernel and elsewhere
    (NFS being the prime example) seems just too high (the original
    explanation given by a
    friend of mine who wrote this was much more colorful, but I guess guys
    like IBM & co. cleaned up
    kernel comments quite a bit ;-)):
    http://lxr.linux.no/linux+v2.6.27.4/fs/namei.c#L2479

    The behavior of mv(1) as defined by POSIX seems to build on top of the
    rename-within-the-same-FS
    guarantee, which, in case of Plan9 is not applicable. Thus it would be
    an interesting thought
    exercise to go over the POSIX text:
    http://www.opengroup.org/onlinepubs/009695399/
    and see how much of the required subdirectory move semantics could be
    preserved even though
    we lack one of the basic building blocks that makes it behave like it
    does on UNIX.

    Thanks,
    Roman.


+ Reply to Thread