On Friday, February 14, 2025, at 3:48 PM, ron minnich wrote: > This is very interesting, but I think the two problems you will hit are (1) > the proliferation of these "," names everywhere and what they mean (do you > include them in readdir? If you do, that's going to at least triple its > length; if you do not, readdir is not showing directory contents, since each > file comes with "benefits") The ,ctl names are never listed in the directory contents. You have to know they are there. Effectively they introduce parameters and operations into the namespace, but not content. Not listing them means that they don't clutter things up, and will not get accidentally copied. (It's not used often, but it's always been possible generally to access files you can't actually see in a directory.)
On Friday, February 14, 2025, at 3:48 PM, ron minnich wrote: > and (2) you will eventually run into a large installed system that already > uses those names -- that kind of thing happens; it will get messy. > > For that reason I kind of fear the way you are overloading path names. It's an important issue. I didn't talk about it above, but the adapter and server encode and decode some characters using %-encoding. I had some examples I removed to keep the post to a reasonable length, but I missed one. :) On Friday, February 14, 2025, at 2:09 AM, Alyssa M wrote: > mtimensec 484184178 > ctimensec 484184178 > name bin > symlink ..%2Fbin > term% > The symlink at the end of the ,ctl file includes a link which is %-encoded to protect the '/' (unnecessarily here actually - that's a bug). The Linux filename: a,b shows up on 9P as a%2Cb and the server translates it back again. It also translates 0x01-0x1F, 0x7F and sometimes %2F, depending on the context, but no others. The mapping is 1:1 so each character has exactly one representation whether encoded or not. So you can use any valid filename on Linux - they just sometimes look different on Plan 9. This means that a Linux filename with an accidental newline on the end (which someone mentioned recently here) e.g. 'foo ' will show up as 'foo%0A' on plan 9. So the Linux namespace is completely unaffected. This only shows up on the wire, or on Plan 9. If someone types $ echo 'dsjfkhdshfsd' >,ctl on Linux it will pass through the adapter and server and create a file called ,ctl on Linux, as you might expect. (actually I just tried this and, embarrassingly, I have a bug! This is a WiP after all. It's supposed to work). It would be possible to build a Plan 9 version of the adapter that hides the ctl file syntax, though of course that would also hide the Linux features. This could be used by Plan 9 software that would be disturbed by the encoding. My intent for this is to not extend the 9P protocol at all - and not make any assumptions about how it might be used in the future - so not borrowing mode bits, for example. I think this is best thought of as a conventional use *of* 9P rather than an extension of it. On Friday, February 14, 2025, at 3:48 PM, ron minnich wrote: > One very good thing about the 9p stat is that it is not intended to be > processed by the kernel. In most cases it gets passed up to userspace. The second version of my experiment packed all the extra Linux metadata into the name field in the Tstat and Twstat, and I had a working implementation between my adapter and server. Unfortunately I found when I tried putting Plan 9 between them that the kernel stomps on the name field! sysstat calls dirsetname. I think this was probably done so that after a bind() you see the new name rather than the old name, and I altered exportfs on my system to use dirfstat, which wasn't doing that, as a work-around. This was on Miller Plan 9. When I found that 9front has fixed fstat the same way I abandoned the second version. I looked into putting the info in the group id field of the Tstat request, but dirstat only allows 64 bytes for the various strings, which is not enough. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T0f2c2342a05a3d6e-M9ab622f573a9c3514f3597a6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
