Re: [9fans] wstat and atomic directory change
It surely would not be conformant to Plan 9 systems, but to the protocol? As far as I can read intro(5), it explicitly excludes slash as a valid character for the Plan 9 OS, but it also explicitly states that the protocol has no such restriction. Be patient: I'm asking because this could be a typo in the intro(5) man page, or in my understanding of its phrasing. Still, using this protocol feature to enable atomic directory change could be useful in my use cases, but I don't want to build yet another 9p2000 extension. Giacomo 2015-01-30 15:13 GMT+01:00 erik quanstrom quans...@quanstro.net: Now, since the protocol does not restrict names (even if Plan 9 does it), I'm wondering if setting the name to a full path starting from root could be used to change atomically the directory of a file (given the write permission on both original and target directory). Obviously I'm not referring to Plan 9 file servers (I guess this would be a non retrocompatbile change), but I'm considering if such interpretation would be wrong (according to the official specifications). A server supporting such behaviour could be considered a 9p2000 conformant server? it would not be conformant. the intro explicitly excludes slash as a valid character. (unlike a dns zone.) and its more detailed explinations are meant to hold for the entire section. but you could still do it, as long as the file servers were the same. - erik
Re: [9fans] wstat and atomic directory change
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).
Re: [9fans] wstat and atomic directory change
On Fri, Jan 30, 2015 at 10:59 AM, Giacomo Tesio giac...@tesio.it wrote: As far as I can read intro(5), it explicitly excludes slash as a valid character for the Plan 9 OS, but it also explicitly states that the protocol has no such restriction. My reading is that a 9p2000 server might allow a filename of the form b/c; e.g. this tree is possible: a |-- b | +-- c | +-- d +-- b/c +-- d Note that a / b / c / d is distinct from a / b/c / d. Plan 9, because of its Unix heritage, will not be able to deal with this, but the protocol has no such limitation. On the other hand, if you bypass the OS and issue a Walk to a/b/c/d, there is a well-defined response required in the protocol -- either open the file with that (impossible) name, or fail. Still, using this protocol feature to enable atomic directory change could be useful in my use cases, but I don't want to build yet another 9p2000 extension. It'll have to be an extension -- a technically incompatible one, though the incompatibilities will not ever happen. --Joel
Re: [9fans] 9atom boot problem
Well, I left the machine on its own and after slightly less than an hour it offered a prompt with some more info, I believe, so now it might be clearer to say what is wrong. See prompt.png. that's expected behavior /sys/lib/newuser will fix that. the lengthy init was all venti. - erik
Re: [9fans] wstat and atomic directory change
Now, since the protocol does not restrict names (even if Plan 9 does it), I'm wondering if setting the name to a full path starting from root could be used to change atomically the directory of a file (given the write permission on both original and target directory). Obviously I'm not referring to Plan 9 file servers (I guess this would be a non retrocompatbile change), but I'm considering if such interpretation would be wrong (according to the official specifications). A server supporting such behaviour could be considered a 9p2000 conformant server? it would not be conformant. the intro explicitly excludes slash as a valid character. (unlike a dns zone.) and its more detailed explinations are meant to hold for the entire section. but you could still do it, as long as the file servers were the same. - erik
[9fans] wstat and atomic directory change
Hi, I'm wondering about the validity of an interpretation of intro(5) and stat(5) that could allow a server to atomically change the directory of a file. From intro(5) http://man.cat-v.org/9front/5/intro The notation string[s] (using a literal s character) is shorthand for s[2] followed by s bytes of UTF-8 text. (Systems may choose to reduce the set of legal characters to reduce syntactic problems, for example to remove slashes from name compo- nents, *but the protocol has no such restriction*. Plan 9 names may contain any printable character (that is, any character outside hexadecimal 00-1F and 80-9F) except slash.). wstat(5) http://man.cat-v.org/9front/5/stat on the other hand does not say much about the name field of Fcall: The name can be changed by anyone with write permission in the parent directory; it is an error to change the name to that of an existing file. Now, since the protocol does not restrict names (even if Plan 9 does it), I'm wondering if setting the name to a full path starting from root could be used to change atomically the directory of a file (given the write permission on both original and target directory). Obviously I'm not referring to Plan 9 file servers (I guess this would be a non retrocompatbile change), but I'm considering if such interpretation would be wrong (according to the official specifications). A server supporting such behaviour could be considered a 9p2000 conformant server? Giacomo