From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <79451b1aea174652598fa3b069103104@proxima.alt.za> To: 9fans@9fans.net Date: Thu, 5 Feb 2015 10:54:50 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] wstat and atomic directory change Topicbox-Message-UUID: 40df5026-ead9-11e9-9d60-3106f5b1d025 > 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. > But you don't know that somewhere further down the hierarchy the target isn't bound to some mount point. What happens then? You asked for atomic, but you can't have it without first descending the entire hierarchy and checking for difficult to detect conditions. >> 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. Well, did you spot that you may have the Internet mounted somewhere in your source directory? Occasionally I forget that I have my NetBSD server bound to my Plan 9 home directory and initiate a search on $home for some lost item. It takes a very long time to complete the search. Now, I may decide to move $home elsewhere... Also, in the absence of symbolic links, you don't get to choose whether to migrate the "node" or the contents. Things get hairy, not just complicated. Lucio.