From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <2CBEED8D-800D-40C8-8182-162695D9FF30@9srv.net> References: <36c9016b7918c302d777f1a605fc107f@brasstown.quanstro.net> <2CBEED8D-800D-40C8-8182-162695D9FF30@9srv.net> Date: Tue, 3 Feb 2015 09:53:20 +0100 Message-ID: From: Giacomo Tesio To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e01493a0ce3ff79050e2b336a Subject: Re: [9fans] wstat and atomic directory change Topicbox-Message-UUID: 3f671cf6-ead9-11e9-9d60-3106f5b1d025 --089e01493a0ce3ff79050e2b336a Content-Type: text/plain; charset=UTF-8 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 : > > > On Jan 30, 2015, at 10:59 , Giacomo Tesio 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). > > > --089e01493a0ce3ff79050e2b336a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, got it.

This annoing thread (sorry)= was due to the fact that the only messages that actually contains the &quo= t;/" marker are Tauth and Tattach (in the aname). I still think that u= sing wstat with such marker to atomically move files among accessible folde= rs would not violate the protocol specification, but actually it would brea= k existing servers and that's is probably enough to define it as an ext= ension to the protocol (say 9P2000.a) so that clients can know if the serve= r 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 folder= s?
I bet that the answer is a control file receiving rc like comm= ands (or any other custom, human readable protocol). Would it be correct?

Something like this:

Given=
mountpoint/
+ first/
=C2=A0 + moveme.txt
+ second/
+ atomically

Doing
echo mv /first/moveme.txt /second/ > mountpoint/atomically

We op= tain either the following or a Rerror:
mountpoint/
+ first/
+ second/
=C2= =A0 + moveme.txt
+ ato= mically


Is it the proper way to achieve such kind of o= perations?


Thanks for your patience= ... :-)


Giacomo

2015-01-30 23:49 GMT+01:0= 0 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 protoc= ol?

No. Joel has it right. Writing a server which allows / in names woul= d mean that the "/" you're slipping into a name wouldn't = always be a directory indicator or name separator. Think of it as the proto= col 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 give= s the best explanation of this, or perhaps the discussion of create in open= (5).



--089e01493a0ce3ff79050e2b336a--