From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <88ac676497dec9efba520307d5a402f0@proxima.alt.za> Date: Thu, 5 Feb 2015 09:37:49 +0100 Message-ID: From: Giacomo Tesio To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] wstat and atomic directory change Topicbox-Message-UUID: 40d63824-ead9-11e9-9d60-3106f5b1d025 Actually I've found a 9 years old mail about Tmove: http://comp.os.plan9.narkive.com/xYi8Vg5d/9fans-fuse-bashing#post40 I'm not an advocate of Tmove in any way, but I can't really grasp the cons. I'm sure that its omission was an explicit design choise, but where I can read about the arguments that lead to such decision? Giacomo 2015-02-05 9:21 GMT+01:00 Giacomo Tesio : > 2015-02-05 5:13 GMT+01:00 : >> >> > But why we don't have Tmove for example? >> >> Because its semantics are much, much more complex and the users need >> to be aware of the difference. > > This shouldn't be so hard to obtain. > > I mean we could simply introduce a new command "rename oldpath > newpath" that only works when both path share the same mount point. > This way the mv commands would keep the old "safe" semantic, while the > new command would protect the user to accidentally disclosure his data > to the world via the cloud. > >> Imagine a Tmove that transfers your >> entire disk contents to the cloud: would you like it to be perceived >> as trivial? What happens if you interrupt it? Worse, what happens if >> you can't interrupt it? > > I won't be drammatic: you can always unplug the enthernet! :-D > > Btw, I see the point. > > > Giacomo