the control file idea is a neat way of doing atomic moves. this has been discussed before, my summary is its not something you need often to justify the pain of trying to implement it correctly - the directory locking has to be done with care to ensure it is all deadlock free.
I do, very rarely, move directories around, generally I just take more care when creating them - knowing it will be a hassle to change later. I also, run fossil and venti, so the copies take no more disk space, only the directory entries. just my 2 cents worth. -Steve > On 3 Feb 2015, at 08:53, Giacomo Tesio <giac...@tesio.it> wrote: > > Ok, got it. > > This annoing thread (sorry) was due to the fact that the only messages that > actually contains the "/" marker are Tauth and Tattach (in the aname). I > still think that using wstat with such marker to atomically move files among > accessible folders would not violate the protocol specification, but actually > it would break existing servers and that's is probably enough to define it as > an extension to the protocol (say 9P2000.a) so that clients can know if the > server supports this semantic or not. > However, as I previously said, I don't think that the world need a new 9p > variant :-D > > Now, what's the proper 9p way that a client could use to tell a syntetic > server to atomically move a syntetic file between syntetic folders? > I bet that the answer is a control file receiving rc like commands (or any > other custom, human readable protocol). Would it be correct? > > Something like this: > > Given > mountpoint/ > + first/ > + moveme.txt > + second/ > + atomically > > Doing > echo mv /first/moveme.txt /second/ > mountpoint/atomically > > We optain either the following or a Rerror: > mountpoint/ > + first/ > + second/ > + moveme.txt > + atomically > > > Is it the proper way to achieve such kind of operations? > > > Thanks for your patience... :-) > > > Giacomo > > 2015-01-30 23:49 GMT+01:00 Anthony Sorace <a...@9srv.net>: >> >> > On Jan 30, 2015, at 10:59 , Giacomo Tesio <giac...@tesio.it> wrote: >> > >> > It surely would not be conformant to Plan 9 systems, but to the protocol? >> >> No. Joel has it right. Writing a server which allows / in names would mean >> that the "/" you're slipping into a name wouldn't always be a directory >> indicator or name separator. Think of it as the protocol accommodating >> systems which use some other marker. >> >> The relevant point is that the "name" in question (which, as you noticed, >> the protocol allows to contain / even though plan9 doesn't) is the name >> *within a directory*, not a full path name. walk(5) probably gives the best >> explanation of this, or perhaps the discussion of create in open(5). >
