From mboxrd@z Thu Jan 1 00:00:00 1970 References: <36c9016b7918c302d777f1a605fc107f@brasstown.quanstro.net> <2CBEED8D-800D-40C8-8182-162695D9FF30@9srv.net> From: Quintile Content-Type: multipart/alternative; boundary=Apple-Mail-DFD1A7D5-5D00-475D-9CC1-23DCDF896506 In-Reply-To: Message-Id: Date: Tue, 3 Feb 2015 09:04:59 +0000 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [9fans] wstat and atomic directory change Topicbox-Message-UUID: 3f6b8840-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail-DFD1A7D5-5D00-475D-9CC1-23DCDF896506 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 oft= en to justify the pain of trying to implement it correctly - the directory l= ocking 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 w= hen 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 th= e directory entries. just my 2 cents worth. -Steve > On 3 Feb 2015, at 08:53, Giacomo Tesio wrote: >=20 > Ok, got it. >=20 > This annoing thread (sorry) was due to the fact that the only messages tha= t actually contains the "/" marker are Tauth and Tattach (in the aname). I s= till think that using wstat with such marker to atomically move files among a= ccessible folders would not violate the protocol specification, but actually= it would break existing servers and that's is probably enough to define it a= s an extension to the protocol (say 9P2000.a) so that clients can know if th= e server supports this semantic or not. > However, as I previously said, I don't think that the world need a new 9p v= ariant :-D >=20 > Now, what's the proper 9p way that a client could use to tell a syntetic s= erver 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? >=20 > Something like this: >=20 > Given > mountpoint/ > + first/ > + moveme.txt > + second/ > + atomically >=20 > Doing > echo mv /first/moveme.txt /second/ > mountpoint/atomically >=20 > We optain either the following or a Rerror: > mountpoint/ > + first/ > + second/ > + moveme.txt > + atomically >=20 >=20 > Is it the proper way to achieve such kind of operations? >=20 >=20 > Thanks for your patience... :-) >=20 >=20 > Giacomo >=20 > 2015-01-30 23:49 GMT+01:00 Anthony Sorace : >>=20 >> > On Jan 30, 2015, at 10:59 , Giacomo Tesio wrote: >> > >> > It surely would not be conformant to Plan 9 systems, but to the protoco= l? >>=20 >> No. Joel has it right. Writing a server which allows / in names would mea= n that the "/" you're slipping into a name wouldn't always be a directory in= dicator or name separator. Think of it as the protocol accommodating systems= which use some other marker. >>=20 >> 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 *wi= thin a directory*, not a full path name. walk(5) probably gives the best exp= lanation of this, or perhaps the discussion of create in open(5). >=20 --Apple-Mail-DFD1A7D5-5D00-475D-9CC1-23DCDF896506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
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 tryi= ng to implement it correctly - the directory locking has to be done with car= e to ensure it is all deadlock free.

I do, very rar= ely, move directories around, generally I just take more care when creating t= hem - knowing it will be a hassle to change later.

= I also, run fossil and venti, so the copies take no more disk space, only th= e 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) w= as due to the fact that the only messages that actually contains the "/" mar= ker are Tauth and Tattach (in the aname). I still think that using wstat wit= h such marker to atomically move files among accessible folders would not vi= olate the protocol specification, but actually it would break existing serve= rs and that's is probably enough to define it as an extension to the protoco= l (say 9P2000.a) so that clients can know if the server supports this semant= ic or not.
However, as I previously said, I don't think that the w= orld need a new 9p variant :-D

Now, what's the prop= er 9p way that a client could use to tell a syntetic server to atomically mo= ve a syntetic file between syntetic folders?
I bet that the answer= is a control file receiving rc like commands (or any other custom, human re= adable protocol). Would it be correct?

Something li= ke this:

Given
mountpoint/
+= first/
  + moveme= .txt
+ second/
+ atomically
<= font face=3D"monospace, monospace">
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 achie= ve such kind of operations?


Thanks f= or your patience... :-)


Giacomo

2015-01-30 2= 3: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 protoco= l?

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 director= y indicator or name separator. Think of it as the protocol accommodating sys= tems which use some other marker.

The relevant point is that the "name" in question (which, as you noticed, th= e protocol allows to contain / even though plan9 doesn't) is the name *withi= n a directory*, not a full path name. walk(5) probably gives the best explan= ation of this, or perhaps the discussion of create in open(5).



= --Apple-Mail-DFD1A7D5-5D00-475D-9CC1-23DCDF896506--