There really is a University of Wollongong. The Wollong Group was a
Unix team in the 70s.
Just to clarify (or not), the Wollongong Group was a company in Palo
Alto (incorporated 6 June 1980 - not quite 70s therefore) whose only
connection to the University of Wollongong was a software license -
On Tue, Nov 2, 2010 at 8:49 AM, Richard Miller 9f...@hamnavoe.com wrote:
Apologies for raising this thread's signal/noise ratio.
Is that possible? :)
-eric
In Hoare's model, livelock and deadlock cannot be distinguished,
This was true in the early days of CSP but the theory has evolved
a fair bit since then. The current model explicitly includes
failures and divergences as part of the semantics of a process (in
addition to its traces); these were
if you hate misinformation, why not provide some correct information to
counter it? i'd hazard a guess that nobody other than you in this thread
knows what you mean by deadly embrace.
On 31 Oct 2010 05:47, Bruce Ellis bruce.el...@gmail.com wrote:
good call. i just hate misinformation. if there
oh shut up. learn.
you want Morgan's phone number?
brucee
On Sun, Oct 31, 2010 at 7:52 PM, roger peppe rogpe...@gmail.com wrote:
if you hate misinformation, why not provide some correct information to
counter it? i'd hazard a guess that nobody other than you in this thread
knows what you
I believe livelock can happen.
On 10/31/10, Bruce Ellis bruce.el...@gmail.com wrote:
oh shut up. learn.
you want Morgan's phone number?
brucee
On Sun, Oct 31, 2010 at 7:52 PM, roger peppe rogpe...@gmail.com wrote:
if you hate misinformation, why not provide some correct information to
Or not. Sorry for the noise.
On 10/31/10, fge...@gmail.com fge...@gmail.com wrote:
I believe livelock can happen.
On 10/31/10, Bruce Ellis bruce.el...@gmail.com wrote:
oh shut up. learn.
you want Morgan's phone number?
brucee
On Sun, Oct 31, 2010 at 7:52 PM, roger peppe
That is correct.
On Sun, Oct 31, 2010 at 9:25 PM, fge...@gmail.com wrote:
I believe livelock can happen.
On 10/31/10, Bruce Ellis bruce.el...@gmail.com wrote:
oh shut up. learn.
you want Morgan's phone number?
brucee
On Sun, Oct 31, 2010 at 7:52 PM, roger peppe rogpe...@gmail.com
an isbn number would be more useful.
On 31 Oct 2010 09:04, Bruce Ellis bruce.el...@gmail.com wrote:
oh shut up. learn.
you want Morgan's phone number?
brucee
On Sun, Oct 31, 2010 at 7:52 PM, roger peppe rogpe...@gmail.com wrote:
if you hate misinformati...
After some research and reading I believe that deadly embrace was first used in:
E. W. Dijkstra EWD108: Een algorithme ter voorkoming van de dodelijke
omarming (in Dutch; An algorithm for the prevention of the deadly
embrace or so I 've been told.
as a synonym for deadlock or actually to
On Sun, Oct 31, 2010 at 2:06 PM, Gorka Guardiola pau...@gmail.com wrote:
So, yeah, deadlock is a synonym for deadly embrace. Yes, in Hoare's model
they are indistinguishable, so when he says deadly embrace, he can refer
to both.
I mean livelock and deadlock are indistinguishable in Hoare's
On Sun, Oct 31, 2010 at 2:07 PM, Gorka Guardiola pau...@gmail.com wrote:
On Sun, Oct 31, 2010 at 2:06 PM, Gorka Guardiola pau...@gmail.com wrote:
So, yeah, deadlock is a synonym for deadly embrace. Yes, in Hoare's model
they are indistinguishable, so when he says deadly embrace, he can refer
http://www.olc.edu/~cdelong/jargon-4.4.7/jargon-4.4.7/html/D/deadly-embrace.html
In the case of 9P I believe the concern in context is waiting for
clunks when the server is dead means the waiter will never die. Can
get particularly bad if its actually a communication failure with
bi-directional
And the sprig of Wattle indeed goes to Gorka.
Then who gets the daub?
EBo --
let's call it rumba and go on.
On Oct 30, 2010, at 1:28 AM, Bruce Ellis bruce.el...@gmail.com wrote:
well you need more books.
On Sat, Oct 30, 2010 at 10:07 AM, roger peppe rogpe...@gmail.com wrote:
the only book by hoare i've got (CSP) doesn't mention a deadly embrace.
On 29 October
good call. i just hate misinformation. if there is any more misleading
trash i will gladly give the offender Morgan's phone number.
brucee
On Sat, Oct 30, 2010 at 8:08 PM, Nemo nemo.m...@gmail.com wrote:
let's call it rumba and go on.
On Oct 30, 2010, at 1:28 AM, Bruce Ellis
On Fri, Oct 29, 2010 at 7:37 AM, Bruce Ellis bruce.el...@gmail.com wrote:
No! Open on an exclusive file has the same races. No problems on
I said I agree it is a problem. Yes, there is a race... Froggie?
A lily-white duck come and swallowed him up,..
What you are saying is that the problem could be something like:
- Tclunk
(do not wait for response)
- Topen (the file is exclusive)
no, because what actually happens is closer to
A: Topen
...
queue request to *another process* to send Tclunk
...
A: Topen
my froggie has been running for four years 24/7. if you haven't read
the BLTJ then styx runs over the PCI ... 4 ixp1200s. asynch clunks.
the only problem is it's 10 times quicker.
the only server that i saw at the labs that had Rclunk semantics was
pb's video magic which i i didn't need. nemo
i don't believe that is possible in my implementation. will check.
brucee
On Fri, Oct 29, 2010 at 8:01 PM, Charles Forsyth fors...@terzarima.net wrote:
What you are saying is that the problem could be something like:
- Tclunk
(do not wait for response)
- Topen (the file is exclusive)
no,
On Fri, Oct 29, 2010 at 11:01 AM, Charles Forsyth fors...@terzarima.net wrote:
What you are saying is that the problem could be something like:
- Tclunk
(do not wait for response)
- Topen (the file is exclusive)
no, because what actually happens is closer to
A: Topen
...
right journal. i'll do some unusual tests and report on the results.
wing-commander has to awake early to attend his mother's 80th birthday party.
back to you on this one.
brucee
On Fri, Oct 29, 2010 at 8:45 PM, Gorka Guardiola pau...@gmail.com wrote:
On Fri, Oct 29, 2010 at 11:01 AM, Charles
On 28 October 2010 21:18, Charles Forsyth fors...@terzarima.net wrote:
the race is that there's nothing to say that the clunk completes before the
process continues on to do something more, including some action that depends
on the clunk completing,
such as simply repeating the open. that
On Fri, Oct 29, 2010 at 02:12:11PM +0100, roger peppe wrote:
so this trick is unsafe in general, but might be ok sometimes.
So is the answer to add semantics to Topen or add a Treopen that obviates
the Tclunk?
++L
On Fri, Oct 29, 2010 at 4:01 AM, Charles Forsyth fors...@terzarima.net wrote:
What you are saying is that the problem could be something like:
- Tclunk
(do not wait for response)
- Topen (the file is exclusive)
no, because what actually happens is closer to
A: Topen
...
On 29 October 2010 15:14, Eric Van Hensbergen eri...@gmail.com wrote:
Just to make sure I understand things correctly, where does this mess
things up with standard (as opposed to synthetic) file systems?
i think that part of the problem is that plan 9 makes no distinction
between standard and
i think that part of the problem is that plan 9 makes no distinction
between standard and synthetic file systems.
perhaps if there was, then optimisations like this could
work a little less haphazardly.
what's a reasonable definition of standard?
- erik
On Fri, Oct 29, 2010 at 10:21 AM, roger peppe rogpe...@gmail.com wrote:
On 29 October 2010 15:14, Eric Van Hensbergen eri...@gmail.com wrote:
Just to make sure I understand things correctly, where does this mess
things up with standard (as opposed to synthetic) file systems?
i think that part
things up with standard (as opposed to synthetic) file systems?
why should a synthetic file system (actually they are all synthetic, i think)
be considered not standard? i thought file systems were the common currency
in the system.
in practise, there is no race if the tree is being imported via
plan9's exportfs(4)
because it services clunk requests synchronously.
there is indeed a race because another process is issuing the clunk(s),
not the one that's doing the open(s).
Do you do completely asynch clunks or just the wait for the response?.
it uses `completely' async clunks, which is why it can be broken.
having the original process send the Tclunk and not wait
for the Rclunk is different. i think it was mentioned last time this
matter came up, and that's
On Fri, Oct 29, 2010 at 10:49 AM, Charles Forsyth fors...@terzarima.net wrote:
things up with standard (as opposed to synthetic) file systems?
why should a synthetic file system (actually they are all synthetic, i
think)
be considered not standard? i thought file systems were the common
having the original process send the Tclunk and not wait
for the Rclunk is different.
ah. having thought about it, i see it's different only in the case of
one process. it isn't different if you have several processes that are
trying to co-operate in an allowed way: failing to let the issuing
On Fri, Oct 29, 2010 at 5:01 AM, Charles Forsyth fors...@terzarima.netwrote:
What you are saying is that the problem could be something like:
- Tclunk
(do not wait for response)
- Topen (the file is exclusive)
no, because what actually happens is closer to
A: Topen
...
this discussion was more interesting in thev UNIX room. froggie hasn't
hung up yet thru a serious thrashing this evening - and all the FSs
are synthetic - it has no disk.
as much as i like philosophizing that's not my way.
brucee
On Sat, Oct 30, 2010 at 2:50 AM, Eric Van Hensbergen
On 29 October 2010 17:01, Charles Forsyth fors...@terzarima.net wrote:
Do you do completely asynch clunks or just the wait for the response?.
it uses `completely' async clunks, which is why it can be broken.
having the original process send the Tclunk and not wait
for the Rclunk is different.
On Fri, Oct 29, 2010 at 12:01 PM, Charles Forsyth fors...@terzarima.netwrote:
Do you do completely asynch clunks or just the wait for the response?.
it uses `completely' async clunks, which is why it can be broken.
having the original process send the Tclunk and not wait
for the Rclunk is
gee i thought i was the first to say deadly-embrace on this thread.
it's not only problematic it's wrong. just reiterating what little
shaun said circa 1999.
brucee
On Sat, Oct 30, 2010 at 3:02 AM, roger peppe rogpe...@gmail.com wrote:
On 29 October 2010 17:01, Charles Forsyth
i don't believe that is possible in my implementation. will check.
it was your implementation i was testing.
on the other hand inferno's sys-export(2) services all requests
(except Tflush) asynchronously,
so the race will always be present.
no, that mistakes the problem. without the change, the issuing process
will see the clunk completed before it attempts any further operations:
no race. with the
erik quanstrom wrote:
what's a reasonable definition of standard?
I've been using 'decent' in much the same way 'standard' or 'disk' is being
used; I'd actually prefer nemo's idea of a QTDECENT qidtype to marking the
file server. The original QTDECENT proposal (actually originally inverted
On Fri, Oct 29, 2010 at 8:49 AM, Charles Forsyth fors...@terzarima.netwrote:
things up with standard (as opposed to synthetic) file systems?
why should a synthetic file system (actually they are all synthetic, i
think)
be considered not standard? i thought file systems were the common
On 29 October 2010 17:17, Bruce Ellis bruce.el...@gmail.com wrote:
gee i thought i was the first to say deadly-embrace on this thread.
it's not only problematic it's wrong. just reiterating what little
shaun said circa 1999.
if deadlock is the issue, isn't it solved just as well
by
I think functional programming or at least category theory gets you into
these upper level abstract ways of thinking
uh oh. is there an analogy to Godwin's Law for mentioning category theory?
Let's try to define 'decent' for this thread -- a decent fileserver is one
on which close()s do not have any client-visible or semantic effect other
than to invalidate the Fid that was passed to them. Lets see how many file
servers we can think of that are 'decent': fossil, kfs, ken, memfs,
I've been using 'decent' in much the same way 'standard' or 'disk' is being
used; I'd actually prefer nemo's idea of a QTDECENT qidtype to marking the
file server. The original QTDECENT proposal (actually originally inverted
logic, in the form of QTCTL) said this about indecent files: this
On Fri Oct 29 13:15:45 EDT 2010, fors...@terzarima.net wrote:
Let's try to define 'decent' for this thread -- a decent fileserver is one
on which close()s do not have any client-visible or semantic effect other
than to invalidate the Fid that was passed to them. Lets see how many file
Category Theory really doesn't say too much in general, but oddly enough it
applies nicely to computer science. What's that mean? :-)
that they're both abstract nonsense.
- erik
On Fri, Oct 29, 2010 at 10:13 AM, Charles Forsyth fors...@terzarima.netwrote:
I think functional programming or at least category theory gets you into
these upper level abstract ways of thinking
uh oh. is there an analogy to Godwin's Law for mentioning category theory?
I hope not... I'm
On Fri, Oct 29, 2010 at 10:17 AM, erik quanstrom
quans...@labs.coraid.comwrote:
On Fri Oct 29 13:15:45 EDT 2010, fors...@terzarima.net wrote:
Let's try to define 'decent' for this thread -- a decent fileserver is
one
on which close()s do not have any client-visible or semantic effect
who said deadlock. it's an easily reproducible situation. rattle the
cage is not a solution.
brucee
On Sat, Oct 30, 2010 at 4:26 AM, erik quanstrom quans...@quanstro.net wrote:
Category Theory really doesn't say too much in general, but oddly enough it
applies nicely to computer science.
On Fri, Oct 29, 2010 at 12:18 PM, Charles Forsyth fors...@terzarima.net wrote:
Let's try to define 'decent' for this thread -- a decent fileserver is one
on which close()s do not have any client-visible or semantic effect other
than to invalidate the Fid that was passed to them. Lets see how
On Fri, Oct 29, 2010 at 10:26 AM, erik quanstrom quans...@quanstro.netwrote:
Category Theory really doesn't say too much in general, but oddly enough
it
applies nicely to computer science. What's that mean? :-)
that they're both abstract nonsense.
- erik
Yeah... the most fun I had
Let's try to define 'decent' for this thread -- a decent fileserver is one
on which close()s do not have any client-visible or semantic effect other
than to invalidate the Fid that was passed to them. Lets see how many file
servers we can think of that are 'decent': fossil, kfs, ken,
Decent
On Fri, Oct 29, 2010 at 11:54 AM, Gorka Guardiola pau...@gmail.com wrote:
Let's try to define 'decent' for this thread -- a decent fileserver is
one
on which close()s do not have any client-visible or semantic effect
other
than to invalidate the Fid that was passed to them. Lets see how
On 29 October 2010 18:47, Bruce Ellis bruce.el...@gmail.com wrote:
who said deadlock. it's an easily reproducible situation. rattle the
cage is not a solution.
sorry then, i misunderstood you. what else did you mean by deadly embrace?
Let's try to define 'decent' for this thread -- a decent fileserver is one
on which close()s do not have any client-visible or semantic effect other
than to invalidate the Fid that was passed to them. Lets see how many file
servers we can think of that are 'decent': fossil, kfs, ken,
back to school for roger
On Sat, Oct 30, 2010 at 6:33 AM, roger peppe rogpe...@gmail.com wrote:
On 29 October 2010 18:47, Bruce Ellis bruce.el...@gmail.com wrote:
who said deadlock. it's an easily reproducible situation. rattle the
cage is not a solution.
sorry then, i misunderstood you.
On Oct 29, 2010, at 10:27 PM, Bruce Ellis bruce.el...@gmail.com wrote:
back to school for roger
On Sat, Oct 30, 2010 at 6:33 AM, roger peppe rogpe...@gmail.com wrote:
On 29 October 2010 18:47, Bruce Ellis bruce.el...@gmail.com wrote:
who said deadlock. it's an easily reproducible
that definition is wrong!
On Sat, Oct 30, 2010 at 7:41 AM, Gorka Guardiola pau...@gmail.com wrote:
On Oct 29, 2010, at 10:27 PM, Bruce Ellis bruce.el...@gmail.com wrote:
back to school for roger
On Sat, Oct 30, 2010 at 6:33 AM, roger peppe rogpe...@gmail.com wrote:
On 29 October 2010
See EWD108 Een algorithme ter voorkoming van de dodelijke
omarming. (An algorithm to avoid the deadly embrace.) in
which Dijkstra describes his Bankers algorithm. 1965 or
earlier. Of course, you may be looking at deadly embrace
from a different point of view.
On Sat, 30 Oct 2010 07:44:58 +1100
On 29 October 2010 21:44, Bruce Ellis bruce.el...@gmail.com wrote:
that definition is wrong!
so point us to the right one then.
grab a book by hoare or morgan.
brucee
On Sat, Oct 30, 2010 at 9:39 AM, roger peppe rogpe...@gmail.com wrote:
On 29 October 2010 21:44, Bruce Ellis bruce.el...@gmail.com wrote:
that definition is wrong!
so point us to the right one then.
the only book by hoare i've got (CSP) doesn't mention a deadly embrace.
On 29 October 2010 23:43, Bruce Ellis bruce.el...@gmail.com wrote:
grab a book by hoare or morgan.
brucee
On Sat, Oct 30, 2010 at 9:39 AM, roger peppe rogpe...@gmail.com wrote:
On 29 October 2010 21:44, Bruce Ellis
well you need more books.
On Sat, Oct 30, 2010 at 10:07 AM, roger peppe rogpe...@gmail.com wrote:
the only book by hoare i've got (CSP) doesn't mention a deadly embrace.
On 29 October 2010 23:43, Bruce Ellis bruce.el...@gmail.com wrote:
grab a book by hoare or morgan.
brucee
On Sat, Oct
you're essentially replacing
f := open(name, ...)
...
close(f)
which runs as a sequential process, and subject to the usual rules for
sequential
composition, by
f := open(name, ...)
...
spawn clunk(f)
which introduces a race with an invisible
no it is not, charles. i rarely disagree with you but the semantics
are preserved, except for changing the behaviour of existing races.
brucee
On Thu, Oct 28, 2010 at 11:12 PM, Charles Forsyth fors...@terzarima.net wrote:
you're essentially replacing
f := open(name, ...)
...
On Thu, Oct 28, 2010 at 2:12 PM, Charles Forsyth fors...@terzarima.net wrote:
you're essentially replacing
f := open(name, ...)
...
close(f)
which runs as a sequential process, and subject to the usual rules for
sequential
composition, by
f := open(name, ...)
Wouldn´t a better way be?:
f := open(name, ...)
tclunk(f);
spawn deallocfid(f); //and whatever needs to be done on Rclunk
Hmm, it would be more like sending the Tclunk and not waiting for the
response. That would mean
that the fid cannot be unmarked for reuse until the response is
One problem I have with delayed clunks is that when you have caches or the like,
close might fail. Not an issue on Inferno, but, I'd still like to be
able to get back in sync
at close time if only to be able to check that everything's ok and
safe in the server.
On Thu, Oct 28, 2010 at 4:30 PM,
On Thu, Oct 28, 2010 at 9:41 AM, Francisco J Ballesteros n...@lsub.org wrote:
One problem I have with delayed clunks is that when you have caches or the
like,
close might fail. Not an issue on Inferno, but, I'd still like to be
able to get back in sync
at close time if only to be able to
Assuming messages are not reordered.
ah, the easy problems can be taken care of by using 1 clunker
and a clunk channel with a fixed buffer. i'd like to know
more about charles' correctness concerns. not that this particular
example is all that useful. cf. nemo
My argument is that I'd like
On Thu, Oct 28, 2010 at 04:56:02PM +0200, Francisco J Ballesteros wrote:
Be there caches of not, I've found that I want to be able to say
I'm done with this file, let me know if everything is done and ok.
You can, just not by using Tclunk.
Of course, if you use 9p with no cache, you know
Nowhere in the manual does it say that. The only protocol-defined way to be
sure that you are coherent is to use Twstat with all arguments NOP. (FWIW,
this may also be superior to checking that Tclunk did not Rerror because the
fid is still live if Twstat Rerrors.)
name 3 in-distribution
Yes, in general, agree, but this was about clunk usage and
semantics, and I think it's important to have the I'm done message
synchronous when you need that.
Btw, I think you mean Tstat, don't you?
I'm not sure Twstat would work that way in practice.
On Thu, Oct 28, 2010 at 11:53 AM, Francisco J Ballesteros n...@lsub.orgwrote:
Yes, in general, agree, but this was about clunk usage and
semantics, and I think it's important to have the I'm done message
synchronous when you need that.
Btw, I think you mean Tstat, don't you?
I'm not sure
On Thu, Oct 28, 2010 at 8:12 AM, Charles Forsyth fors...@terzarima.netwrote:
you're essentially replacing
f := open(name, ...)
...
close(f)
which runs as a sequential process, and subject to the usual rules for
sequential
composition, by
f := open(name, ...)
Also, if that is racy, isn't this at least analogous?
i don't think so: that instance is entirely at the discretion of the programmer.
it would be analogous if the text of the program actually contained `spawn
clunk(f)',
but i was trying to represent the effects of the rewriting the system would
On Thu, Oct 28, 2010 at 4:18 PM, Charles Forsyth fors...@terzarima.netwrote:
the race is that there's nothing to say that the clunk completes before the
process continues on to do something more, including some action that
depends on the clunk completing,
such as simply repeating the open.
On Thu, Oct 28, 2010 at 4:55 PM, Nemo nemo.m...@gmail.com wrote:
i have decent servers that wait for clunk to operate on written data once
it's complete. all octopus spoolers do that.
Heh; when I wrote 'decent', I was recalling the old proposed QTDECENT qid
type. I didn't mean to impugn your
months ago, i did test an example on the system that just works, by the way,
and it did fail. it often takes a few attempts for it to fail,
because it depends on scheduling (often the system completes the clunk before
returning to the original process), but there's nothing to stop it failing
On Thu, Oct 28, 2010 at 10:18 PM, Charles Forsyth fors...@terzarima.net wrote:
the race is that there's nothing to say that the clunk completes before the
process continues on to do something more, including some action that depends
on the clunk completing,
such as simply repeating the open.
No! Open on an exclusive file has the same races. No problems on
Froggie .. no servers with clunk semantics. The first I encountered
was Bosch's video streamer. Nemo obviously has concerns.
Catch a run.
brucee
On Fri, Oct 29, 2010 at 10:51 AM, Gorka Guardiola pau...@gmail.com wrote:
On Thu,
I explained to VS that Research Inferno has been doing it for 10 years.
A much simpler approach. Solves your problems. Sorry that
wing-commander can't package it for today.
brucee
On Wed, Oct 27, 2010 at 3:23 PM, erik quanstrom quans...@quanstro.net wrote:
I just committed a very simple
Sorry that wing-commander can't package it for today.
sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but
one of the sprogs had a prang with the bally old semantics and the other brass
hats ordered it back to the boffins
I'm reaching out for Vaughan right now.
You might google for that if that's an unknown...
On Wed, Oct 27, 2010 at 3:53 PM, Gorka Guardiola pau...@gmail.com wrote:
On Wed, Oct 27, 2010 at 3:50 PM, Charles Forsyth fors...@terzarima.net
wrote:
Sorry that wing-commander can't package it for today.
On Wed, Oct 27, 2010 at 3:50 PM, Charles Forsyth fors...@terzarima.net wrote:
Sorry that wing-commander can't package it for today.
sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but
one of the sprogs had a prang with the bally old semantics and the other
brass
On Wed, Oct 27, 2010 at 9:53 AM, Gorka Guardiola pau...@gmail.com wrote:
On Wed, Oct 27, 2010 at 3:50 PM, Charles Forsyth fors...@terzarima.net
wrote:
Sorry that wing-commander can't package it for today.
sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze,
but one of
On Wed, Oct 27, 2010 at 8:50 AM, Charles Forsyth fors...@terzarima.net wrote:
Sorry that wing-commander can't package it for today.
sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but
one of the sprogs had a prang with the bally old semantics and the other
brass
It does. And eliminates deadly embraces when servers misbehave.
No wuckers.
brucee
On Thu, Oct 28, 2010 at 2:54 AM, Venkatesh Srinivas
m...@endeavour.zapto.org wrote:
Oh, no, it wasn't meant as a defense! It was much more a 'hmm, only two
hours can produce fairly solid performance gains;
Hi folks,
I just committed a very simple implementation of asynchronous TClunk to
inferno-npe. The implementation will only defer sending clunks when MCACHE
is specified on the mount (via the new -j option to Inferno's mount,
analogous to Plan 9's mount -C) and when the file is not marked
I just committed a very simple implementation of asynchronous TClunk to
inferno-npe. The implementation will only defer sending clunks when MCACHE
is specified on the mount (via the new -j option to Inferno's mount,
analogous to Plan 9's mount -C) and when the file is not marked ORCLOSE. The
92 matches
Mail list logo
