From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] mv vs cp Message-ID: <20011008182230.H28720@cackle.proxima.alt.za> References: <20011008144648.63B1319A0B@mail.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20011008144648.63B1319A0B@mail.cse.psu.edu>; from rob pike on Mon, Oct 08, 2001 at 10:46:44AM -0400 Date: Mon, 8 Oct 2001 18:22:32 +0200 Topicbox-Message-UUID: 02087efe-eaca-11e9-9e20-41e7f4b1d025 On Mon, Oct 08, 2001 at 10:46:44AM -0400, rob pike wrote: > > 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). > Wait, I'm being obtuse here. Do you see a "mv-tree thingy" as essential to a "rename" function? I'm going along with Dave's suggestion that the kernel determine the fids of source and destination (and I'm using fids loosely because I'm not really familiar with them) and then submit then (Tmv or, my preference, Trename) to the fileserver for actioning. Moves that require data to be tranferred are forbidden in my model (they can be handled by user-space operations, I suppose) and damage to the namespace is the user's responsibility. Again, in my ignorance, I assume that one would create an anonymous node at the destination and point it (in some fashion I really don't know enough about, but I'll be pleased to have my nose rubbed into the details of, whichever way) to the fileserver entity originally pointed at by the source. The original connection would then be removed and name transfer take place (roughly). Please educate me on this, reading the documents and man pages didn't make the picture any clearer. I certainly can't agree that the fileserver won't know that a file is elsewhere: if the nameserver can't tell which files it serves we have a serious problem. Now, if by the time the fileserver considers a file it has an id that looks like a local one, we certainly have a crisis, but I'm hoping that the kernel can prevent this _at_the_root_ of the rename, yet I hear continuous references to the remainder of the graph, which puzzles me because I don't see rename navigating the graph at all. I'm sure I'm wrong, so please tell me where. As for Alexander's example, I really need to look at it more carefully, I don't understand the details at all. ++L