9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] mv vs cp
@ 2001-10-09 17:16 presotto
  0 siblings, 0 replies; 87+ messages in thread
From: presotto @ 2001-10-09 17:16 UTC (permalink / raw)
  To: 9fans

On Tue Oct  9 12:35:49 EDT 2001, tb+usenet@becket.net wrote:
> 
> (One thing; please clear up my ignorance: sometimes a symlink is used
> for the benefit of all the users; where in a Plan 9 system do I put a
> "bind" such that it is the automatic default for all users in that
> way?)

That's what /lib/namespace is.  It represents a global namespace for
all users on a machine.  Of course, the user can then do whatever
he/she wants but serves as the default namespace.

/lib/namespace and your profile also represent persistence which is
another useful property you get from symlinks.


^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-11  3:19 anothy
  0 siblings, 0 replies; 87+ messages in thread
From: anothy @ 2001-10-11  3:19 UTC (permalink / raw)
  To: 9fans

yeah, but whoever's _got_ your fileserver can do
pretty much whatever they please.



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-11  3:00 okamoto
  0 siblings, 0 replies; 87+ messages in thread
From: okamoto @ 2001-10-11  3:00 UTC (permalink / raw)
  To: 9fans

Do you have some special Plan 9 file server kernel?

Kenji



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-11  2:18 Russ Cox
  0 siblings, 0 replies; 87+ messages in thread
From: Russ Cox @ 2001-10-11  2:18 UTC (permalink / raw)
  To: 9fans

That's okay, whoever runs your file server
can read your mail box too.

Russ


^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-11  1:06 okamoto
  0 siblings, 0 replies; 87+ messages in thread
From: okamoto @ 2001-10-11  1:06 UTC (permalink / raw)
  To: 9fans

>Before you start saying that shared /tmp or all-mighty root are bad ideas,

I hate all-mighty root user because s/he can read my mail box.

Kenji



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-10 13:18 forsyth
  0 siblings, 0 replies; 87+ messages in thread
From: forsyth @ 2001-10-10 13:18 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

yes, i don't think the desire to move directory contents was at issue,
for that and other examples.
the question was whether to implement an optimisation for the
case where source and target names are on the same file store.

since in both the Plan 9 and Unix cases, it's necessary to copy,
plan 9 settles for renaming files and directories (in their containing directories),
but does not allow either files or directories to be moved without copying.
(depending on what the move operation means in the presence of
arbitrary per-process binds and mounts, it might be impossible to
provide a sensible definition of move from a user's point of view anyway.)

some versions of unix attempt to allow directories to be moved,
that typically doesn't work across file systems, so mv ends
up copying anyway, doing pretty much what plan 9 would do.
on unix, i might like to do {mv /tmp/superbigvideofile $home/videofarm/birthday}
without having the system copy a big file, but that usually doesn't work.
so on unix i probably would do {recordvideo $home/videofarm/tmp.$pid}
and rename it later, which is how i'd get round the problem on plan 9.


[-- Attachment #2: Type: message/rfc822, Size: 1761 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] mv vs cp
Date: Wed, 10 Oct 2001 08:49:09 GMT
Message-ID: <9pvcjf$k1f$1@inputplus.demon.co.uk>

Hi Dave,

> Also, to be brutal for a minute,
> why *do* people want to move directories around:

Typical reason is wanting to re-arrange a directory structure after a
better layout becomes clearer with use.


Ralph.

^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-10  1:45 okamoto
  0 siblings, 0 replies; 87+ messages in thread
From: okamoto @ 2001-10-10  1:45 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 222 bytes --]

I responded your comment before I read another comment on EROS, 
which said EROS is persistent.  Maybe it indicates it has no concept 
of directory graph.   If so, I understand your behaviour here.

Thanks

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 2215 bytes --]

From: Richard <greon@best.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] mv vs cp
Date: Mon, 08 Oct 2001 22:46:41 -0700
Message-ID: <E15qpiz-0000EM-00@localhost>

okamoto@granite.cias.osakafu-u.ac.jp writes:

>I don't understand your stance anymore...
>Aren't you who recommended us EROS?
>Isn't the file system of EROS directory graph?

my stance is that OS designers should learn about
capability OSes like EROS and that Plan 9 should 
be made more attractive to people used to Unix's mv
command.  do you detect an inconsistency in
that?

^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-09 16:59 rog
  0 siblings, 0 replies; 87+ messages in thread
From: rog @ 2001-10-09 16:59 UTC (permalink / raw)
  To: 9fans

> I'm not expert in Plan 9, but it seems to me that it breaks it for the
> user.

surely it's "broken for the user" the moment the user can't move a
file from one place to another for any reason at all (e.g.  because
the file is on a different disk, or a different location on the
network, or whatever).

under Windows, where disks and networks are visible at the top level
of the file tree to the user, perhaps this is slightly more
understandable, but where the file tree is unified, the difference
between "can't because it's on a different disk" and "can't because
it's in a different directory" is surely one of degree not of kind?

  rog.



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-09 16:39 forsyth
  2001-10-10  8:49 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 87+ messages in thread
From: forsyth @ 2001-10-09 16:39 UTC (permalink / raw)
  To: 9fans

>>Is this just an example of the "New Jersey" preference for simplicity
>>of implementation over the "Cambridge" preference for correctness and
>>completeness?

``correctness and completeness''?  this sounds like the result of
a self-assessment exercise.



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-09 12:25 rob pike
  2001-10-09 16:18 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 87+ messages in thread
From: rob pike @ 2001-10-09 12:25 UTC (permalink / raw)
  To: 9fans

> walk away from symlinks because it was hard to get right, more than
> because  philosophically they were 'wrong'? 

Symlinks were put in to make it possible to link directories from user
mode and to have cross-file system links.  Plan 9 does both those
things another way.  I have never felt the need for symbolic links in
Plan 9.

They also have some ugly properties.  I find the delayed evaluation
mystifying sometimes.  Also, although they are used to implement
cross-system links, they live on a single file system.  For example,
/usr/rob might be a link to /home/rob even though /usr and /home live
on different disks or even different servers, which means /usr has a
file that talks about /home, a file on a different machine.  Besides
the creepiness of that, the delayed evaluation can bite you hard, the
permanence of the link can be troublesome, and this little piece of
name space stored as a time bomb somewhere in the network rather than
in the client's representation of its resources is poor compartment-
alization and therefore lousy design.  And why on earth does ls
default to showing you the link rather than what it points to?

This does not imply that Plan 9's name space was designed in reaction
to symbolic links, of course, but at least some of us did observe that
symbolic links were little more than a disgusting hack and that there
had to be a better way.  Ken was already thinking about that way when
all this was happening back in the early '80s.  I believe that the
design he came up with, Plan 9's name space, is indeed better,
although it has some problems of its own and doesn't exactly cover
symlinks (the lack of permanence of the mount table comes to mind).
The unification of all naming operations into a single data structure
(the mount table), the well-defined evaluation, and the clean
separation of file servers and name spaces, and most important the
user-modifiable, per-process name space were all improvements.

As I said in my `dot-dot' paper, Unix still hasn't recovered from all
the problems wrought by the introduction of symbolic links.  It is a
lesson, although not a new one, that the ugly, supposedly temporary
hack of symlinks became a permanent fixture of the system, and one
that people argue for passionately, mistaking the addressing of the
issue for a true solution to the problem (c.f.  Plan 9's # notation).

-rob



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-09 12:05 forsyth
  0 siblings, 0 replies; 87+ messages in thread
From: forsyth @ 2001-10-09 12:05 UTC (permalink / raw)
  To: 9fans

>>Surely hard links couldn't point to directories, so it was only about
>>alternate paths to leaf objects. Thats not the same as a GOTO loop.

they could, but (at least by 5th eidtion) it was restricted to the super-user.
in fact, that was how directory rename was implemented, by setuid mv using
link and unlink.  races?  argument checking?  ``values of [beta] will give rise to dom!''.
the . and .. names were actual links in the directory, put there by the mkdir command.
the rmdir command did the 3 unlinks (for ., .., and the name itself).



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-09  1:46 okamoto
  2001-10-09  5:46 ` Richard
  0 siblings, 1 reply; 87+ messages in thread
From: okamoto @ 2001-10-09  1:46 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 139 bytes --]

I don't understand your stance anymore...
Aren't you who recommended us EROS?
Isn't the file system of EROS directory graph?

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 2501 bytes --]

From: Richard <greon@best.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] mv vs cp
Date: Mon, 08 Oct 2001 08:37:59 -0700
Message-ID: <E15qcTf-0007iJ-00@localhost>

jmk@plan9.bell-labs.com writes:

>How often do you do a move of a whole tree, not just a rename?
>I can't remember the last time I did other than a rename or a copy
>of a few files. But I'm probably not the average user and I don't
>ever use a local disc.

I do it all the time (at least 5, 10 times a month) on Linux, because
I'm kind of compulsive about maintaining just the right names for data
files I care about.

The point is not that it is necessary, but rather that millions are
already used to being able to do it, and letting them do it on Plan 9
(provided of course it is implemented cleanly) will lower the obstacle
to their become Plan 9 users.

^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-08 16:54 presotto
  0 siblings, 0 replies; 87+ messages in thread
From: presotto @ 2001-10-08 16:54 UTC (permalink / raw)
  To: 9fans

There are a number of solutions being aired here:

1) avoiding a copy the data and perhaps some of the metadata
2) on a recursive call, avoiding a message per file
3) getting it right if two people/programs do it simultaneously

The first 2 are performance, the last is adding something that
you can't do with our current mv.

(3) seems to be a solving a problem in the wrong place.
If two people simultaneously move a graph, the result is going to
be confusing/scarey even if everything resides in the same file
server and we somehow manage to lock the whole file server while
it happens, since in the absolute best case one is going to see
his graph inexpicably disappear.  This is more a social problem than
a technical one.  If programs are going to do it, they'ld better
set locks somewhere and have some agreement on what name space is
being looked at.

In plan 9, as rob pointed out, there's no way
for the file server to know what your name space is.
Therefore, the application or kernel has to walk the whole
subspace being moved and then try to create a set of requests
to the relevant file servers.  Not only will this set not 
be locked but you'll have done a large amount of walking
to figure out what to do.  Because of this, I think we're stuck with
forgetting about (2) and (3) without majorly changing how mounts
work.

(1), on the otherhand, may be possible.  It still requires that
you walk both paths and make sure they end up on the same
server.  Then you can have a message that says 'mv fid1 to fid2'.
I think that that's the best you can do, i.e., file by file.
You might improve that to a directory mv but you'ld have to
know that nothing was mounted below the source directory.
That is probably more trouble than its worth.

The file server can always say 'error - unimplemented' and
you can fall back to the create/copy/rm.  That way you
don't have to require exportfs, ftpfs, upas/fs and a
slurry of other impossible to understand servers to
change.

By the way, think about the following scenario:

	mkdir x
	> x/y
	bind -a x .
	mv y z

What do you want to happen here?  Should y change directory when
renamed to z or not?

On the whole, I don't think it worth the trouble.  As the above
example points out, the result of mv is already pretty confusing
in our namespace.  Whatever solution you choose should make things
less confusing, not more.


^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-08 16:11 anothy
  0 siblings, 0 replies; 87+ messages in thread
From: anothy @ 2001-10-08 16:11 UTC (permalink / raw)
  To: 9fans

// But the idea of a filename, booked into the filename space which says
// 
// 	"I may not resolve all the time, but if I do, I point to <x>"
// 
// Isn't so inherently evil to me.

it is to me. how do i know if it does or doesn't? what's the condition?
what's the behaviour if it doesn't? hell, what's the behaviour if it _does_
resolve? questions of whether to follow links or not... it's just never
seemed worth it. the _only_ time i've missed symlinks in Plan 9 is in
importing packages from elsewhere. this simpler version of what you
have above, which _wouldn't_ seem inherently evil to me, would be:
	"I point to <x>, where x is a set of data."
much simpler, much easier to implement (uh, like, files?), much more
consistant, and thus easier to understand. even multiple hard links
under unix satisfy this: if it's there, it points to a certain set of data.
no condidtions on that.

// Pointing out M$ has .LNK isn't going to help my cause much is it

no, not likely. it's been a while since i've poked at any Windows box,
but under at least '95 and '98revA, drop into a shell prompt and try
to cat^Wtype foo.lnk. it's not even built into the FS, it's interpreted by
the tools, like explorer.
-α.



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-08 14:46 rob pike
  2001-10-08 15:00 ` Alexander Viro
  2001-10-08 16:22 ` Lucio De Re
  0 siblings, 2 replies; 87+ messages in thread
From: rob pike @ 2001-10-08 14:46 UTC (permalink / raw)
  To: 9fans

> We accept that the "trees" (you're perfectly right about directed
> graphs) are rooted at the same fileserver, I think.

Do you?  A mv-tree thingy would require the server to know the name
space of the client to get this right.  The server doesn't know that
one of the files in the client's tree is somewhere else.  I honestly
don't see a reasonable way to do this right, even if we don't worry
about race conditions (and we do).

-rob



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-08 13:03 rob pike
  2001-10-08 14:40 ` Lucio De Re
  0 siblings, 1 reply; 87+ messages in thread
From: rob pike @ 2001-10-08 13:03 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-08 13:00 rob pike
  2001-10-09  9:04 ` Douglas A. Gwyn
  0 siblings, 1 reply; 87+ messages in thread
From: rob pike @ 2001-10-08 13:00 UTC (permalink / raw)
  To: 9fans

> writing correct tree-walker
> that would deal gracefully with cross-directory renames is _nasty_.

This is because the file system isn't a tree and hasn't been for a very
long time. It's a graph, but people still talk about it as thought it were
a tree and write simple recursive algorithms and get themselves in
trouble all the time.

-rob



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-08  6:54 nigel
  0 siblings, 0 replies; 87+ messages in thread
From: nigel @ 2001-10-08  6:54 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 131 bytes --]

Well, I've seen only one Windows machine infected with a virus my
whole life. Am I to conclude that viruses are not a problem?


[-- Attachment #2: Type: message/rfc822, Size: 2137 bytes --]

From: George Michaelson <ggm@apnic.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] mv vs cp
Date: Mon, 08 Oct 2001 16:49:43 +1000
Message-ID: <4615.1002523783@apnic.net>


> Any time when attacker feels like that.  System where nonprivileged users
> can cause filesystem corruption is broken.  Period.
> 

Umm yes, but Alexander, when was the last time you *saw* one of these?

-George
--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net


^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-08  5:05 jmk
  2001-10-08  5:45 ` Mike Haertel
                   ` (4 more replies)
  0 siblings, 5 replies; 87+ messages in thread
From: jmk @ 2001-10-08  5:05 UTC (permalink / raw)
  To: 9fans

How often do you do a move of a whole tree, not just a rename?
I can't remember the last time I did other than a rename or a copy
of a few files. But I'm probably not the average user and I don't
ever use a local disc.


^ permalink raw reply	[flat|nested] 87+ messages in thread
* RE: [9fans] mv vs cp
@ 2001-10-07 21:20 nigel
  0 siblings, 0 replies; 87+ messages in thread
From: nigel @ 2001-10-07 21:20 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Don't know the name, but it's been available mail order here for years.


[-- Attachment #2: Type: message/rfc822, Size: 1219 bytes --]

From: presotto@closedmind.org
To: 9fans@cse.psu.edu
Subject: RE: [9fans] mv vs cp
Date: Sun, 7 Oct 2001 15:11:27 -0400
Message-ID: <20011007191129.4E4CB1998A@mail.cse.psu.edu>

Sorry about that.  I didn't see that the return address was
9fans.  But if anyone can come up with the name of the tool,
I'ld be a happy camper...

^ permalink raw reply	[flat|nested] 87+ messages in thread
* RE: [9fans] mv vs cp
@ 2001-10-07 19:11 presotto
  2001-10-08  7:33 ` Skip Tavakkolian
  0 siblings, 1 reply; 87+ messages in thread
From: presotto @ 2001-10-07 19:11 UTC (permalink / raw)
  To: 9fans

Sorry about that.  I didn't see that the return address was
9fans.  But if anyone can come up with the name of the tool,
I'ld be a happy camper...


^ permalink raw reply	[flat|nested] 87+ messages in thread
* RE: [9fans] mv vs cp
@ 2001-10-07 18:53 presotto
  0 siblings, 0 replies; 87+ messages in thread
From: presotto @ 2001-10-07 18:53 UTC (permalink / raw)
  To: 9fans

It was time.  I got cable too.  Now I've seen a $19.95
tool I want, though I can't remember the name.  It's a socket
wrench that's essentially a cylinder filled with pins that can
contour around a nut.  Seen it?  Even cooler than the metriwrench.


^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-07 16:23 jmk
  2001-10-08  4:28 ` Lucio De Re
  2001-10-08  9:42 ` Thomas Bushnell, BSG
  0 siblings, 2 replies; 87+ messages in thread
From: jmk @ 2001-10-07 16:23 UTC (permalink / raw)
  To: 9fans

As Dave points out, there are a lot of balls in the air during
an atomic 'rename'. 4.2BSD introduced the 'rename' system call,
and as an alpha/beta tester for 4.1[abc] and 4.2BSD I can testify
to how long it took to get it right and how much ugly code was
involved.

--jim


^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-07 12:43 presotto
  2001-10-07 13:01 ` Lucio De Re
  2001-10-07 17:26 ` philw
  0 siblings, 2 replies; 87+ messages in thread
From: presotto @ 2001-10-07 12:43 UTC (permalink / raw)
  To: 9fans

On Sun Oct  7 02:30:21 EDT 2001, lucio@proxima.alt.za wrote:
> Am I being utterly obtuse, or does it really make sense to duplicate
> then delete files when moving them to another directory?

It could be done, it just depends on what you'ld like to pay for it,
its just code after all.

You'ld need to create a new file system message (Tmv) and a new system
call (mv).  The kernel would have to start by walking both paths and
determine if they came from the same mount point, error if not.  It would
then send a Tmv message with 2 fids.  The file system would determine
if it could do it and return an error if not (might not be space, ...).
The file system structure would also have to be changed to accomodate it, we
don't have links, though the copy on write makes that not too terrible.

We consciously traded simplicity for it.  It hasn't bothered us enough to
regret it, perhaps because a real file server is faster than kfs, perhaps
because we don't do a lot of file moving.

If you think otherwise, that's why the source is open.  Have a look and
see what you'ld need to change and then convince others that the change
is worth it.  Implementations are no big deals.  New file system messages
are since you have to change lots of file servers to go with it.

> I had the distribution archives in /dist under "kfs" and decided to do
> the following:
> 
> 	% cd /dist
> 	% mkdir plan9
> 	% mv *.9gz plan9
> 
> the machine is still busy copying plan9.9gz :-(
> 
> In this case, a "rename" would have been appropriate.  Is it not
> possible to determine whether it would work and resort to cp+rm if
> it doesn't?

This is indeed what happened, mv determined it wouldn't work and did a
cp+rm when it found it wouldn't.



^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-07  7:02 forsyth
  0 siblings, 0 replies; 87+ messages in thread
From: forsyth @ 2001-10-07  7:02 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 66 bytes --]

wstat gives a directory entry a new name;
it doesn't move it.


[-- Attachment #2: Type: message/rfc822, Size: 2314 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] mv vs cp
Date: Sun, 7 Oct 2001 08:29:00 +0200
Message-ID: <20011007082859.I28720@cackle.proxima.alt.za>

Am I being utterly obtuse, or does it really make sense to duplicate
then delete files when moving them to another directory?

I had the distribution archives in /dist under "kfs" and decided to do
the following:

	% cd /dist
	% mkdir plan9
	% mv *.9gz plan9

the machine is still busy copying plan9.9gz :-(

In this case, a "rename" would have been appropriate.  Is it not
possible to determine whether it would work and resort to cp+rm if
it doesn't?

In fact, a rename command would be an adequate compromise.  I see
there's a "kfs" command called "rename" but the man page does not
specify its actual scope.  Should I have used that (one file at the
time) instead?

++L

^ permalink raw reply	[flat|nested] 87+ messages in thread
* Re: [9fans] mv vs cp
@ 2001-10-07  6:35 Russ Cox
  2001-10-08  9:41 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 87+ messages in thread
From: Russ Cox @ 2001-10-07  6:35 UTC (permalink / raw)
  To: 9fans

> In this case, a "rename" would have been appropriate.  Is it not
> possible to determine whether it would work and resort to cp+rm if
> it doesn't?

How would you determine whether it would work?
How would you specify it to the underlying 9P server?

Don't use kfs rename; it doesn't move files 
between directories.

Russ


^ permalink raw reply	[flat|nested] 87+ messages in thread
* [9fans] mv vs cp
@ 2001-10-07  6:29 Lucio De Re
  2001-10-07  6:42 ` Quinn Dunkan
  0 siblings, 1 reply; 87+ messages in thread
From: Lucio De Re @ 2001-10-07  6:29 UTC (permalink / raw)
  To: 9fans mailing list

Am I being utterly obtuse, or does it really make sense to duplicate
then delete files when moving them to another directory?

I had the distribution archives in /dist under "kfs" and decided to do
the following:

	% cd /dist
	% mkdir plan9
	% mv *.9gz plan9

the machine is still busy copying plan9.9gz :-(

In this case, a "rename" would have been appropriate.  Is it not
possible to determine whether it would work and resort to cp+rm if
it doesn't?

In fact, a rename command would be an adequate compromise.  I see
there's a "kfs" command called "rename" but the man page does not
specify its actual scope.  Should I have used that (one file at the
time) instead?

++L


^ permalink raw reply	[flat|nested] 87+ messages in thread

end of thread, other threads:[~2001-10-12  9:19 UTC | newest]

Thread overview: 87+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-09 17:16 [9fans] mv vs cp presotto
  -- strict thread matches above, loose matches on Subject: below --
2001-10-11  3:19 anothy
2001-10-11  3:00 okamoto
2001-10-11  2:18 Russ Cox
2001-10-11  1:06 okamoto
2001-10-10 13:18 forsyth
2001-10-10  1:45 okamoto
2001-10-09 16:59 rog
2001-10-09 16:39 forsyth
2001-10-10  8:49 ` Thomas Bushnell, BSG
2001-10-09 12:25 rob pike
2001-10-09 16:18 ` Thomas Bushnell, BSG
2001-10-09 12:05 forsyth
2001-10-09  1:46 okamoto
2001-10-09  5:46 ` Richard
2001-10-08 16:54 presotto
2001-10-08 16:11 anothy
2001-10-08 14:46 rob pike
2001-10-08 15:00 ` Alexander Viro
2001-10-08 15:14   ` Markus Friedl
2001-10-08 16:22 ` Lucio De Re
2001-10-08 13:03 rob pike
2001-10-08 14:40 ` Lucio De Re
2001-10-08 13:00 rob pike
2001-10-09  9:04 ` Douglas A. Gwyn
2001-10-09 11:43   ` George Michaelson
2001-10-10  8:57     ` Douglas A. Gwyn
2001-10-10 11:50       ` Borja Marcos
2001-10-10 11:53         ` Borja Marcos
2001-10-08  6:54 nigel
2001-10-08  5:05 jmk
2001-10-08  5:45 ` Mike Haertel
2001-10-08  6:27   ` Lucio De Re
2001-10-08  6:25 ` Lucio De Re
2001-10-08  9:50 ` Douglas A. Gwyn
2001-10-08  9:51 ` Thomas Bushnell, BSG
2001-10-08 15:37 ` Richard
2001-10-08 16:02   ` William Josephson
2001-10-07 21:20 nigel
2001-10-07 19:11 presotto
2001-10-08  7:33 ` Skip Tavakkolian
2001-10-07 18:53 presotto
2001-10-07 16:23 jmk
2001-10-08  4:28 ` Lucio De Re
2001-10-08  4:49   ` Alexander Viro
2001-10-08  6:10     ` George Michaelson
2001-10-08  6:34       ` Alexander Viro
2001-10-08  6:49         ` George Michaelson
2001-10-08  7:00           ` Lucio De Re
2001-10-08  7:13             ` George Michaelson
2001-10-08  7:44               ` Alexander Viro
2001-10-08  7:28             ` Alexander Viro
2001-10-08  6:54       ` Lucio De Re
2001-10-08  7:10         ` George Michaelson
2001-10-08  8:28           ` Lucio De Re
2001-10-08  9:51     ` Thomas Bushnell, BSG
2001-10-08 10:30       ` Alexander Viro
2001-10-09  9:03         ` Thomas Bushnell, BSG
2001-10-09  9:33           ` Alexander Viro
2001-10-09 15:58             ` Thomas Bushnell, BSG
2001-10-09 16:43               ` davel
2001-10-10  8:49                 ` Ralph Corderoy
2001-10-10  8:49                 ` Thomas Bushnell, BSG
2001-10-10  9:48                   ` davel
2001-10-11  9:10                     ` Thomas Bushnell, BSG
2001-10-11 10:54                       ` davel
2001-10-12  9:19                         ` Thomas Bushnell, BSG
2001-10-09 16:46               ` Alexander Viro
2001-10-10  8:50                 ` Thomas Bushnell, BSG
2001-10-10 10:29                   ` Alexander Viro
2001-10-10  1:05               ` erik quanstrom
2001-10-10  2:15                 ` david presotto
2001-10-10  4:54                   ` Skip Tavakkolian
2001-10-10  8:30                 ` davel
2001-10-08 10:34       ` Boyd Roberts
2001-10-08  9:50   ` Douglas A. Gwyn
2001-10-08 11:13     ` Lucio De Re
2001-10-08  9:42 ` Thomas Bushnell, BSG
2001-10-07 12:43 presotto
2001-10-07 13:01 ` Lucio De Re
2001-10-07 17:26 ` philw
2001-10-07  7:02 forsyth
2001-10-07  6:35 Russ Cox
2001-10-08  9:41 ` Thomas Bushnell, BSG
2001-10-07  6:29 Lucio De Re
2001-10-07  6:42 ` Quinn Dunkan
2001-10-07  9:17   ` Lucio De Re

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).