Re: [9fans] bug in exportfs

On 15 February 2016 at 01:05, arisawa wrote: > filtering of exportfs is handy if it works well. > ... The whole short discussion was useful, thanks. It gave me a few ideas, prompted by exportfs, including about filtering.

Re: [9fans] bug in exportfs

On 15 February 2016 at 15:30, erik quanstrom wrote: > > sadly among its other sins, the plan 9 webserver does use .httplogin but that's just an ordinary name; in fact, it's exactly that name that's hidden, nothing to do with .: httpd.c: * don't show the contents of

Re: [9fans] bug in exportfs

leading dot is a Jedi mind trick that only works on the weak minded. "these aren't the files you' re looking for" On Mon, Feb 15, 2016 at 7:38 AM erik quanstrom wrote: > > My point was that under the circumstances we are stuck with people who > > DO use the leading dot

Re: [9fans] bug in exportfs

> My point was that under the circumstances we are stuck with people who > DO use the leading dot to make files disappear from directory listings > and they won't budge :-) what the intent of the leading dot might be is not recorded in the file system and one can ignore the convention as one

Re: [9fans] bug in exportfs

> Yes, although that convention isn't in Plan 9, and it might be worthwhile > reconsidering how and why it is used. > If for configuration files, perhaps they should be stored elsewhere; if for > access control (eg, .htaccess), perhaps > groups would be better, with dynamic group membership

Re: [9fans] bug in exportfs

On Mon Feb 15 07:08:06 PST 2016, lu...@proxima.alt.za wrote: > > Ah, my memory fails me, mostly due to too much time on Unipress machines in > > the 1980's. > > Rob's explanation for how the hidden files came about is out there in the > wild. I recall enjoying it. Probably one of Rob Pike's

Re: [9fans] bug in exportfs

> Ah, my memory fails me, mostly due to too much time on Unipress machines in > the 1980's. Rob's explanation for how the hidden files came about is out there in the wild. I recall enjoying it. Probably one of Rob Pike's blog entries or somesuch on his own web site. Lucio.

Re: [9fans] bug in exportfs

> Not in Plan 9. They do not disappear from directory listings in Plan 9 (or > even Plan 9 Port). > There isn't even a -a option, because all names are listed. I suppose you have a point in that exportfs is not likely to be used outside of a Plan 9 environment, but that is a little parochial,

Re: [9fans] bug in exportfs

On 15 February 2016 at 12:44, wrote: > My point was that under the circumstances we are stuck with people who > DO use the leading dot to make files disappear from directory listings > and they won't budge :-) > Not in Plan 9. They do not disappear from directory listings

Re: [9fans] bug in exportfs

> There is no "leading dot" convention in Plan 9. > That's in BSD-derived UNIX, and it's the result of an simplified hack in > ls, which was fixed in Seventh Edition. > If you can open it, it's obviously not "hidden": it's just inconvenient to > use with grep *. I was hoping to put that issue to

Re: [9fans] bug in exportfs

On 15 February 2016 at 10:55, wrote: > > Charles, I think Kenji has a point and you are diverting the > discussion . > Not really: I'm trying to suggest possibilities for "what are you trying to achieve" (by hiding dot files, say), and then alternative mechanisms for that.

Re: [9fans] bug in exportfs

Ah, my memory fails me, mostly due to too much time on Unipress machines in the 1980's. Sent from my iPad > On Feb 15, 2016, at 7:08 AM, Charles Forsyth > wrote: > > >> On 15 February 2016 at 10:55, wrote: >> >> Whereas I agree that the

Re: [9fans] bug in exportfs

On 15 February 2016 at 10:55, wrote: > > Whereas I agree that the leading-dot convention ought to be buried, in > reality (a) it is not going to just go away and (b) if it was so > readily accepted, it must have fulfilled a need. > There is no "leading dot" convention in

Re: [9fans] bug in exportfs

> Yes, although that convention isn't in Plan 9, and it might be > worthwhile reconsidering how and why it is used. If for configuration > files, perhaps they should be stored elsewhere; if for access control > (eg, .htaccess), perhaps groups would be better, with dynamic group > membership

Re: [9fans] bug in exportfs

On 15 February 2016 at 01:05, arisawa wrote: > for example, assume we want to exclude all files of name that begins with > “.”, > then it is probably difficult to do so using only nsfile. > Yes, although that convention isn't in Plan 9, and it might be worthwhile

Re: [9fans] bug in exportfs

an alternative is just to have an exclude file listing files/directories that cannot be read or walked to. brucee On 15 February 2016 at 12:05, arisawa wrote: > Hello, > > > 2016/02/15 7:57、Charles Forsyth のメール： > > > > > > On 14 February

Re: [9fans] bug in exportfs

Hello, > 2016/02/15 7:57、Charles Forsyth のメール： > > > On 14 February 2016 at 16:38, wrote: > i could imagine the filtering being usefull when cpu'ing to foreign machines, > as a server can easily compromize your system when cpu exports your

Re: [9fans] bug in exportfs

On 14 February 2016 at 16:38, wrote: > i could imagine the filtering being usefull when cpu'ing to foreign > machines, > as a server can easily compromize your system when cpu exports your whole > local namespace > You'd still be better off using a custom nsfile to

Re: [9fans] bug in exportfs

On 13 February 2016 at 14:26, Charles Forsyth wrote: > I really wonder about the pattern-matching code being there at all. One interesting thing about the implementation is that it goes so far as to edit the result of directory reads, so excluded names can't be seen

Re: [9fans] bug in exportfs

On 14 February 2016 at 10:27, hiro <23h...@gmail.com> wrote: > You mean this? No, there was a handful of Plan 9 patents, mainly to do with aspects and applications of computable name spaces and related services.

Re: [9fans] bug in exportfs

i could imagine the filtering being usefull when cpu'ing to foreign machines, as a server can easily compromize your system when cpu exports your whole local namespace. i dont know if anyone has done this tho. -- cinap

Re: [9fans] bug in exportfs

You mean this? http://inventors.about.com/od/tstartinventions/ss/TelephonePatent.htm On 2/14/16, Prof Brucee wrote: > Totally agree. I've never needed exportfs filtering. It's not in the > patent. > On 14/02/2016 1:27 AM, "Charles Forsyth"

Re: [9fans] bug in exportfs

On 22 December 2015 at 10:02, arisawa wrote: > > The difficulty is in the pattern matching rule. > If we want to export only /usr/glenda, then the pattern matching filer > must pass > /usr > /usr/glenda > and must not pass > /usr/ > I really wonder about the

Re: [9fans] bug in exportfs

Totally agree. I've never needed exportfs filtering. It's not in the patent. On 14/02/2016 1:27 AM, "Charles Forsyth" wrote: > > On 22 December 2015 at 10:02, arisawa wrote: > >> >> The difficulty is in the pattern matching rule. >> If we

Re: [9fans] bug in exportfs

No. The difficulty is in the pattern matching rule. If we want to export only /usr/glenda, then the pattern matching filer must pass /usr /usr/glenda and must not pass /usr/ have you get solution? > 2015/12/22 18:25、Peter Hull のメール： > > Mr Arisawa, > Did you get any

Re: [9fans] bug in exportfs

Thanks for your replay. however I don’t understand the intention of the manual. real needs in exporting is to export some different directories. it is impossible to do so under current code. can anyone show an example that exports two or more directories? > 2015/12/17 20:40、Peter Hull

Re: [9fans] bug in exportfs

On Wed, Dec 16, 2015 at 11:31 PM, arisawa wrote: > It seems cpu command is buggy in -P option. > the sources of the problem is in command option -P of exportfs. I had a look at the manpage for exportfs(4), it says: "For a file to be exported, all lines with a prefix +