Re: [9fans] mv on directory - Plan9

This is a discussion on Re: [9fans] mv on directory - Plan9 ; On Nov 1, 2008, at 5:00 AM, 9fans-request@9fans.net wrote: > I wonder why 'mv' is not allowed to act on directories. I found > somewhere this argument: > ---- >>> What should mv do to a `tree' that resides on ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Re: [9fans] mv on directory

  1. Re: [9fans] mv on directory


    On Nov 1, 2008, at 5:00 AM, 9fans-request@9fans.net wrote:

    > I wonder why 'mv' is not allowed to act on directories. I found
    > somewhere this argument:
    > ----
    >>> What should mv do to a `tree' that resides on multiple file servers?
    >>> If you can't do something right, sometimes it's not worth doing at
    >>> all.
    >>>
    >>> -rob

    >
    >
    > but this doesn't go well in my ears when put alongside with the
    > existence of recursive rm ('rm -r').



    There is dircp (in tar(1)) for moving trees around, or the long-form
    " @{cd fromdir && tar cp .} | @{cd todir && tar xT} ", if you prefer.
    Directories in Plan 9 are files. Sometimes synthetic files, unions of
    two or more trees. Rob Pike's somewhat gnomic explanation makes
    perfect sense, especially if you read about exactly what mv(1) will
    and won't do to a directory.

    I am 100% behind any effort to uncover bugs and inconsistencies and
    make the system better. But "behavior deviates from the similarly-
    named command in lunix" cannot be the definition of "bug."

    Again, "What should mv do to a tree that resides on multiple file
    servers?"


    -Josh



  2. Re: [9fans] mv on directory

    > There is dircp (in tar(1)) for moving trees around, or the long-form " @{cd
    > fromdir && tar cp .} | @{cd todir && tar xT} ", if you prefer.


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

    > But "behavior deviates from the similarly-named command in
    > lunix" cannot be the definition of "bug."


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

    > Again, "What should mv do to a tree that resides on multiple file servers?"


    what about: mv dirA dirB ==
    mkdir dirB
    dircp dirA dirB
    rm -r dirA

    .... if you are able to 'rm -r' (which also may span multiple
    fileservers) than I don't see any trouble with moving the directories.
    Ruda


  3. Re: [9fans] mv on directory

    On Sat, Nov 1, 2008 at 9:17 AM, Rudolf Sykora wrote:
    >> There is dircp (in tar(1)) for moving trees around, or the long-form " @{cd
    >> fromdir && tar cp .} | @{cd todir && tar xT} ", if you prefer.

    >
    > I know that. It's a copy, not move.
    >
    >> But "behavior deviates from the similarly-named command in
    >> lunix" cannot be the definition of "bug."

    >
    > I just can't see any reason why to mention anything about any bug. I
    > didn't do that.
    >
    >> Again, "What should mv do to a tree that resides on multiple file servers?"

    >
    > what about: mv dirA dirB ==
    > mkdir dirB
    > dircp dirA dirB
    > rm -r dirA
    >
    > ... if you are able to 'rm -r' (which also may span multiple
    > fileservers) than I don't see any trouble with moving the directories.
    >


    I would imagine that 99% of the time (more?) the behavior people
    desire would be what you describe. There are two parts to the
    problem: the application and the protocol. To have the protocol
    handle rename of anything other than single element (which may be the
    root of a tree) on a single file server is difficult -- however, it
    seems perfectly sensible to have the application fall back to the
    functionality you describe. Does anyone rely on the 'mv' command
    always having the atomic properties of a wstat?

    -eric


  4. Re: [9fans] mv on directory

    On Nov 1, 2008, at 8:04 AM, Eric Van Hensbergen wrote:
    > On Sat, Nov 1, 2008 at 9:17 AM, Rudolf Sykora
    > wrote:
    >>
    >>> Again, "What should mv do to a tree that resides on multiple file
    >>> servers?"

    >>
    >> what about: mv dirA dirB ==
    >> mkdir dirB
    >> dircp dirA dirB
    >> rm -r dirA
    >>
    >> ... if you are able to 'rm -r' (which also may span multiple
    >> fileservers) than I don't see any trouble with moving the
    >> directories.
    >>

    >
    > I would imagine that 99% of the time (more?) the behavior people
    > desire would be what you describe.


    But what is the behavior? Is it literally the above set of rc commands?
    Or is there an atomicity expectation as well? After dircp dirA dirB
    the contents of dirB could be surprising, especially given the later
    rm -r dirA.

    It seems that mv(1) was taken as far as one could go in terms
    of having a non-surprising behavior: mv dir1/file dir2/file is
    equivalent to cp -x dir1/file dir2/file ; rm dir1/file.

    Thanks,
    Roman.


  5. Re: [9fans] mv on directory

    On Sat, Nov 1, 2008 at 4:05 PM, Roman Shaposhnik wrote:
    > On Nov 1, 2008, at 8:04 AM, Eric Van Hensbergen wrote:
    >>
    >> I would imagine that 99% of the time (more?) the behavior people
    >> desire would be what you describe.

    >
    > But what is the behavior? Is it literally the above set of rc commands?
    > Or is there an atomicity expectation as well? After dircp dirA dirB
    > the contents of dirB could be surprising, especially given the later
    > rm -r dirA.
    >
    > It seems that mv(1) was taken as far as one could go in terms
    > of having a non-surprising behavior: mv dir1/file dir2/file is
    > equivalent to cp -x dir1/file dir2/file ; rm dir1/file.
    >


    Well, I suppose there'd have to be a bit more wrapping around checking
    for failure of the copy before the erase -- but otherwise perhaps I'm
    being dense and don't see the surprise. Its clear you won't get the
    atomicity, but there's no clear way to obtain that -- and, as I said,
    I'm not sure who depends on that when using the mv command.

    -eric


  6. Re: [9fans] mv on directory

    On Nov 1, 2008, at 7:12 PM, Eric Van Hensbergen wrote:
    > On Sat, Nov 1, 2008 at 4:05 PM, Roman Shaposhnik wrote:
    >> On Nov 1, 2008, at 8:04 AM, Eric Van Hensbergen wrote:
    >>>
    >>> I would imagine that 99% of the time (more?) the behavior people
    >>> desire would be what you describe.

    >>
    >> But what is the behavior? Is it literally the above set of rc
    >> commands?
    >> Or is there an atomicity expectation as well? After dircp dirA dirB
    >> the contents of dirB could be surprising, especially given the later
    >> rm -r dirA.
    >>
    >> It seems that mv(1) was taken as far as one could go in terms
    >> of having a non-surprising behavior: mv dir1/file dir2/file is
    >> equivalent to cp -x dir1/file dir2/file ; rm dir1/file.
    >>

    >
    > Well, I suppose there'd have to be a bit more wrapping around checking
    > for failure of the copy before the erase -- but otherwise perhaps I'm
    > being dense and don't see the surprise.


    Well, it could be that I'm just too easily surprised. I'll try to
    explain. Suppose
    that you have the following sequence of directory renames (all within
    the single FS
    tree):
    (1) /a -> /b
    (2) /a/1 -> /a/2

    Because of the POSIX atomicity guarantee the minute you have (1) succeed
    your (2) will fail because /a/1 no longer exists. The following, on
    the other
    hand:
    (1) mv-dircp /a /b
    (2) mv-dircp /a/1 /a/2
    is likely to produce /b/2, which, I find surprising. As a side note:
    the results
    are even more surprising/subtle when renames need to be serialized
    in a DSCM. There's been quite a few debates on what DSCM does it
    better. Just like Al said -- somebody at UCB had one heck of a trip ;-)

    > Its clear you won't get the
    > atomicity, but there's no clear way to obtain that -- and, as I said,
    > I'm not sure who depends on that when using the mv command.



    I would argue that personally I've been conditioned by POSIX to
    be able to do:
    $ mv .hidden-from-everybody
    and expect all references to anything in the original file hierarchy
    to fail from that point on.

    Thanks,
    Roman.


+ Reply to Thread