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 <giacomo@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 <giacomo@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).
>