From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200206061022.g56AMBc26586@zamenhof.cs.utwente.nl> To: 9fans@cse.psu.edu Subject: Re: [9fans] spaces in file/dir names? (and acme)? In-reply-to: Your message of "Thu, 06 Jun 2002 10:11:15 +0200." <603bbcf5ff85234aac6bf2afdd608ff4@plan9.escet.urjc.es> References: <603bbcf5ff85234aac6bf2afdd608ff4@plan9.escet.urjc.es> From: Axel Belinfante Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 6 Jun 2002 12:22:10 +0200 Topicbox-Message-UUID: a72bd070-eaca-11e9-9e20-41e7f4b1d025 [I started this as an off-list reply (the 'w.r.t the code' part at the end); then I started talking about how 'substfs' works, and decided to send it to the list, because it seemed suited there as well. It got a bit long:-( ] > : To solve my particular case at hand (playing mp3 files made available > : via u9fs, where I don't want to do any special work at the remote end), > : I resorted to writing (hacking) what I've named so far 'substfs', > : ... > : When it is slightly more complete (and there is interest?) > > I'd love both to take a look at it and to try it. > Another use would be to use mp3info as one of your edit > programs to replace file names > with the author/title kept inside the mp3. I'm learning now -- thanks! -- I had not realized there is that info in mp3 (but now that you mention it, I recall seeing it displayed). Still, we have to see how easy it is to add to the current approach I have taken. Right now the 'substfs' just gets a 9p message from the user, edits it if needed, forwards it to the remote server (e.g. u9fs), gets the response from the remote server, edits it if needed, and returns the (potentially edited) response to the user. Editing is only done on file names. So, there is a clear one-to-one mapping between messages. I'm aware of the fact that this may break, e.g. when editing the data of a read on a big directory edits it such that the new filenames are so much longer that the edited data no longer fits in a single message. It's just a prototype. The right solution would probably be to keep slightly more state in substfs. Also, substfs does just use/handle the fids and qids of the user resp. the remote server. This means that if substfs wants to do its 'own' requests to the remote fs (like: to get (part of) the mp3 data to get to the mp3 info), it has to choose fids that do not conflict with those of the user. Still, an interesting question is whether I could use this approach for the 'file system stacking problem' I asked about on the list, about a year ago. The idea of stacking was the following: to have one file server (A) that generates a file system with a regular structure (like the tcp directories in /net or the mail message directories of upas/fs), and then have a second file server (B) that adds a file to each of the subdirectories generated by A, where the name of the new (added) file is the same for all the subdirectories, but the contents of the new files depend on the contents of one or more of the 'original' files in the directory. And, Ideally, achieving this all in B without having to make special provisions in A. The basic idea/question was to use (combine) file servers in the same way as (text) filters are used in a pipe line. Some of the replies I got then included references to existing code that does something like this already; at that time I only had a look at that code but did not do anything more -- and I haven't had a recent look at that code while working on substfs -- probably I should have. W.r.t. the code -- if you don't mind seeing code that might benefit from some good reviewing I can send you it 'as is' (as I'm using it right now), because, of course I would like to clean it up before 'general distribution', but on the other hand it is sort-of working (sufficiently well for my needs) right now, so I fear it might take a while before I get to cleaning up. Regards, Axel.