Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1473 > unrolled thread

OS_GBPB 12 in a Wimp task

Back to article view | Back to comp.sys.acorn.programmer

Contents

  OS_GBPB 12 in a Wimp task Christopher Bazley <cs99cjb@gmail.com> - 2012-03-06 14:33 -0800
    Re: OS_GBPB 12 in a Wimp task jeff <jeffrey.a.doggett@gmail.com> - 2012-03-07 00:02 -0800
      Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-08 22:33 +0000
        Re: OS_GBPB 12 in a Wimp task Christopher Bazley <cs99cjb@gmail.com> - 2012-03-10 10:22 -0800
          Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-10 21:04 +0000
            Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-10 23:11 +0100
              Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-11 09:10 +0000
                Re: OS_GBPB 12 in a Wimp task Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-03-11 10:41 +0000
                Re: OS_GBPB 12 in a Wimp task Steve Fryatt <news@stevefryatt.org.uk> - 2012-03-11 11:06 +0000
                Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-11 17:56 +0100
                  Re: OS_GBPB 12 in a Wimp task Gavin Wraith <gavin@wra1th.plus.com> - 2012-03-11 18:25 +0000
                    Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-12 00:33 +0100
                      Re: OS_GBPB 12 in a Wimp task Gavin Wraith <gavin@wra1th.plus.com> - 2012-03-12 11:56 +0000
                        Re: OS_GBPB 12 in a Wimp task Martin Wuerthner <spamtrap@mw-software.com> - 2012-03-12 16:44 +0100
                        Re: OS_GBPB 12 in a Wimp task druck <news@druck.org.uk> - 2012-03-12 20:57 +0000
                          Re: OS_GBPB 12 in a Wimp task Martin Wuerthner <spamtrap@mw-software.com> - 2012-03-12 22:26 +0100
                          Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-13 17:50 +0100
                          Re: OS_GBPB 12 in a Wimp task jgharston <jgh@arcade.demon.co.uk> - 2012-03-13 10:15 -0700
                  Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-13 07:34 +0000
                    Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-14 06:00 +0100
                      Re: OS_GBPB 12 in a Wimp task Christopher Bazley <cs99cjb@gmail.com> - 2012-03-15 02:40 -0700
                        Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-15 14:55 +0100
                          Re: OS_GBPB 12 in a Wimp task "Ste (news)" <steve@revi11.plus.com> - 2012-03-15 14:46 +0000
                            Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-15 18:44 +0100
                            Re: OS_GBPB 12 in a Wimp task Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-03-15 19:44 +0000
                              Re: OS_GBPB 12 in a Wimp task Alan Adams <alan@adamshome.org.uk> - 2012-03-15 20:36 +0000
                              Re: OS_GBPB 12 in a Wimp task Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-03-15 20:26 +0000
                                Re: OS_GBPB 12 in a Wimp task Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-03-16 06:12 +0100
                          Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-15 20:34 +0000
                            Re: OS_GBPB 12 in a Wimp task Alan Adams <alan@adamshome.org.uk> - 2012-03-15 21:04 +0000
                              Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-16 00:17 +0000
          Re: OS_GBPB 12 in a Wimp task Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-03-10 23:58 +0000
            Re: OS_GBPB 12 in a Wimp task Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-03-11 10:43 +0000
            Re: OS_GBPB 12 in a Wimp task jeff <jeffrey.a.doggett@gmail.com> - 2012-03-12 03:03 -0700
              Re: OS_GBPB 12 in a Wimp task Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-03-12 10:44 +0000
              Re: OS_GBPB 12 in a Wimp task Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-03-13 07:44 +0000
                Re: OS_GBPB 12 in a Wimp task jeff <jeffrey.a.doggett@gmail.com> - 2012-03-13 03:06 -0700
    Re: OS_GBPB 12 in a Wimp task druck <news@druck.org.uk> - 2012-03-07 10:08 +0000

Page 2 of 2 — ← Prev page 1 [2]

#1508

On Mar 14, 5:00 am, Rick Murray <heyrickmail-use...@yahoo.co.uk>
wrote:
> > Surely to fix this problem, FilerAction would have to read a
> complete
> > directory in one go into an internal list, and then work through
> it, say
> > first dealing with all the files, and then recursing into each
>
> directory

After discussion with a colleague, I concluded that the possible
solutions were:
1) A versioning filing system. The value passed in R4 refers to a
snapshot of the directory contents at the time of the first call to
OS_GBPB.
2) Deprecate passing any value of R4 other than the start value.
3) Accept that in reality R4 is used as a random-access file index by
RISC OS applications. Document this and rewrite offending filing
systems to cope efficiently. Let the user deal with consequences of
concurrent modifications to a directory.

I marginally favour 3 over 2, because it seems more in keeping with
the spirit of RISC OS (i.e. it lets you do stupid things and it's your
own funeral).

> That's how I'd do it - scan *all* directories and subdirectories
> making an index of directories. Then start moving or deleting them
> from the deepest up, reading actual directory contents as the
> directory is encountered. This may be suboptimal for floppies or
> Econet; but we've moved on...

I don't think it's a matter of storage access but the fact that the
caller of OS_GBPB would need an enormous buffer for results and the
CPU would spend ages inside the kernel populating the buffer (thereby
halting multi-tasking). Worse, there is no way that the caller could
know the buffer size requirements ahead of time, and they might change
between one call to OS_GBPB and the next! (Imagine task A trying
repeatedly to determine the required buffer size whilst task B adds
files to the same directory.)

Incidentally, I am alarmed at some contributors' suggestions that R4
be interpreted as a pointer. Way to let programs crash the operating
system! This is not how to implement an opaque handle between user
space and kernel space,

> [plus, it isn't within the realms of possibility for it to trap and
> be aware of filesystem activity in other tasks]

Indeed, druck's standard anti-RISC OS rant completely missed the
point.

--
Chris Bazley

[toc] | [prev] | [next] | [standalone]

#1509

On Thu, 15 Mar 2012 02:40:06 -0700 (PDT), Christopher Bazley 
<cs99cjb@gmail.com> wrote:

> CPU would spend ages inside the kernel populating the buffer 
(thereby
> halting multi-tasking). Worse, there is no way that the caller could

Really? I'd have thought USB to a FAT32 device would take a big wodge 
of code, but my 200MHz ARM video recorder can do it on the fly while 
recording... How long would it *really* take to read a directory 
structure from disc and botch it into something GBPB can return?


> Incidentally, I am alarmed at some contributors' suggestions that R4
> be interpreted as a pointer. Way to let programs crash the operating
> system! This is not how to implement an opaque handle between user

I thought it was the FS using R4 as a pointer? The PRM says nothing 
about it except that it is the value you sholpuld pass in the next 
call. StrongHelp's OS manual is a little stronger telling you in 
flashing neon to never assume anything about what R4 represents...


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1510

In article <almarsoft.333093024920706560@news.orange.fr>,
   Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> How long would it *really* take to read a directory structure from disc
> and botch it into something GBPB can return?

And the answer is, of course, it depends... how about enumerating a
directory with 30,000 objects in it via Sunfish with a slow NFS server and a
10baseT network?

Ta,

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

[toc] | [prev] | [next] | [standalone]

#1511

On Thu, 15 Mar 2012 14:46:00 +0000 (GMT), "Ste (news)" 
<steve@revi11.plus.com> wrote:

> directory with 30,000 objects in it via Sunfish with a slow NFS 
server and a
> 10baseT network?

That's a whole world of pain no matter how you look at it.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1512

"Ste (news)" <steve@revi11.plus.com> wrote:

> And the answer is, of course, it depends... how about enumerating a
> directory with 30,000 objects in it via Sunfish with a slow NFS server and
> a 10baseT network?

I've just added a whole lot of files to a Dropbox directory and the Dropbox
client is uploading those to the Dropbox servers.  The tooltip text on the
systray icon was clearly written by someone with a sense of humour for it
says -

  Uploading 6234 files (9.8KB/sec, a long time left. Grab a Snickers)

which I rather like.  Why so slow?  Because it's a Virgin Media connection
and I've uploaded a couple of GB in the last two days and I've been "traffic
managed".

-- 
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsreplyaaa@wingsandbeaks.org.uk replacing "aaa" by "284".  

[toc] | [prev] | [next] | [standalone]

#1514

In message <mpro.m0xytt00d1oi90104@wingsandbeaks.org.uk.invalid>
          Jeremy Nicoll - news posts 
<jn.nntp.scrap007@wingsandbeaks.org.uk> wrote:

> "Ste (news)" <steve@revi11.plus.com> wrote:

>> And the answer is, of course, it depends... how about enumerating a
>> directory with 30,000 objects in it via Sunfish with a slow NFS server and
>> a 10baseT network?

> I've just added a whole lot of files to a Dropbox directory and the Dropbox
> client is uploading those to the Dropbox servers.  The tooltip text on the
> systray icon was clearly written by someone with a sense of humour for it
> says -

>   Uploading 6234 files (9.8KB/sec, a long time left. Grab a Snickers)

Better than the usual Windows estimates - for one large copy of a 
directory tree the estimates, at 5 second intervals, were 6 hrs, 16 
hrs, 5 minutes, done.

> which I rather like.  Why so slow?  Because it's a Virgin Media connection
> and I've uploaded a couple of GB in the last two days and I've been "traffic
> managed".



-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#1515

In article <mpro.m0xytt00d1oi90104@wingsandbeaks.org.uk.invalid>,
   Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk>
wrote:
> Because it's a Virgin Media connection and I've uploaded a couple
> of GB in the last two days and I've been "traffic managed".

I thought the recent adverts say 'unlimited'.

-- 
Chris Johnson

[toc] | [prev] | [next] | [standalone]

#1518

On Thu, 15 Mar 2012 20:26:40 +0000 (GMT), Chris Johnson 
<chrisjohnson+news@spamcop.net> wrote:

>> of GB in the last two days and I've been "traffic managed".
> I thought the recent adverts say 'unlimited'.

Advertising standards said "unlimited" can be limited if said limits 
don't affect the majority. With allies like that, consumers might as 
well give up hope.

That said, <10K/sec is a kick in the teeth.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1513

In message <almarsoft.333093024920706560@news.orange.fr>
 on 15 Mar 2012 Rick Murray  wrote:

> On Thu, 15 Mar 2012 02:40:06 -0700 (PDT), Christopher Bazley 
> <cs99cjb@gmail.com> wrote:
> 
> > Incidentally, I am alarmed at some contributors' suggestions that R4 be
> > interpreted as a pointer. Way to let programs crash the operating system!
> > This is not how to implement an opaque handle between user
> 
> I thought it was the FS using R4 as a pointer?

Yes, but Chris is quite right that actually implementing a filing system like
that would be a bad idea.  I'm afraid it was my loose choice of words.  I was
trying to make the point that after the initial call to OS-GBPB with R4=0,
the filing system might return in R4 a value which then does not change over
subsequent calls until finally R4=-1 is returned at the end, so "remembering
previous values of R4" is scarcely an improvement for winding backwards
through the directory.  The filing system might be using R4 as a pointer to a
structure where the actual context is being kept internally.

I should, of course, have used the word "handle".

Implementing a filing system along these lines is problematic in itself, as
the caller is not obliged to keep going till it gets R4=-1, so the filing
system has no way of knowing that the handle and context can be disposed of.

My inclination (from the filing system author's point of view) is that there
are quite a few weird and wonderful filing systems where it would be pretty
hard to treat R4 as a random access file index into the directory.  But I
appreciate that the application author doesn't always have much option if the
application is to multi-task and behave responsively.  Perhaps we need a way
of asking the filing system to go backwards, as well as forwards?!  But that
would involve a new API, which would be even less likely to be achievable
than the alternatives of rewriting FileAction (and other apps) or rewriting
the filing systems!

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1516

In message <4c94017152.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

<snip>

> My inclination (from the filing system author's point of view) is that there
> are quite a few weird and wonderful filing systems where it would be pretty
> hard to treat R4 as a random access file index into the directory.  But I
> appreciate that the application author doesn't always have much option if the
> application is to multi-task and behave responsively.  Perhaps we need a way
> of asking the filing system to go backwards, as well as forwards?!  But that
> would involve a new API, which would be even less likely to be achievable
> than the alternatives of rewriting FileAction (and other apps) or rewriting
> the filing systems!

Aren't we missing something? RISC OS is a single-user operating 
system. If the user chooses to modify a directory while the same user 
is using the filer to copy to or from it, then they should expect 
slightly odd behaviour.

It would of course be a slightly different matter if a background 
process did the copy while the user was modifying things (backup?) or 
modified things while the user copied (email arriving?)

Why an application would need to go backwards I can't imagine, but 
surely if it did, then it would either need to have counted the files 
scanned so far, and rescan to the same number, or remember the name 
and rescan. Possibly both, in case either an intervening file had been 
deleted (count is too large) or the target file was deleted (scan 
forever). Either way, surely it's the application's responsibility - 
the documentation says "pass back the value you received in R4". The 
only other valid value is 0 - start a new scan.

-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#1517

In message <934f047152.Alan.Adams@laptop.adamshome.org.uk>
 on 15 Mar 2012 Alan Adams  wrote:

> In message <4c94017152.Matthew@sinenomine.freeserve.co.uk>
>           Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> 
> <snip>
> 
> > My inclination (from the filing system author's point of view) is that
> > there are quite a few weird and wonderful filing systems where it would
> > be pretty hard to treat R4 as a random access file index into the
> > directory.  But I appreciate that the application author doesn't always
> > have much option if the application is to multi-task and behave
> > responsively.  Perhaps we need a way of asking the filing system to go
> > backwards, as well as forwards?!  But that would involve a new API, which
> > would be even less likely to be achievable than the alternatives of
> > rewriting FileAction (and other apps) or rewriting the filing systems!
> 
> Aren't we missing something? RISC OS is a single-user operating 
> system. If the user chooses to modify a directory while the same user 
> is using the filer to copy to or from it, then they should expect 
> slightly odd behaviour.
> 
> It would of course be a slightly different matter if a background 
> process did the copy while the user was modifying things (backup?) or 
> modified things while the user copied (email arriving?)

The problem we have been discussing with FilerAction occurs, I think, during
Move or Delete operations.

Suppose you had selected a bunch of files in a directory, shift-dragged them
to move them elsewhere, and while that was proceeding, chose to delete
another file in the same directory.  The way FilerAction is implemented,
relying as it does on the unstated behaviour of FileCore filing systems,
means that on other filing systems unaware of this problem you might find
that the wrong files end up being moved.

You might find this irritating, especially if you then selected all the
remaining ones and deleted them without checking first.
 
> Why an application would need to go backwards I can't imagine, but 
> surely if it did, then it would either need to have counted the files 
> scanned so far, and rescan to the same number, or remember the name 
> and rescan.

That would be an alternative, but we are trying to avoid re-doing the
scanning: some contributors have pointed out that scanning directories can be
slow on some filing systems.

I mentioned going backwards because that's what FilerAction does, in effect
(see the rest of the thread).  After deleting or moving files from a
directory, FilerAction deducts the number of files processed so far from R4
before getting the next batch of filenames from OS_GBPB.  This is not
guaranteed to work with all filing systems out there because the requirement
that it be supported has never been spelled out to filing system developers.

> Either way, surely it's the application's responsibility -  the
> documentation says "pass back the value you received in R4". The only other
> valid value is 0 - start a new scan.

We'e all agreed what the documentation says: the trouble is FilerAction
abuses R4.  And going back to the original question, Chris was asking whether
it is considered safe to preserve and use the R4 value across Wimp_Polls.  In
the general case, it is not, but you might then end up with the desktop not
multi-tasking while an application deals with all 30,000 files in an
NFS-mounted directory across a 10Mb network (to give Steve's example).

I feel as though this thread is starting to go round in circles (like a hard
disc?!).

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1486

In article
<dea93483-8f06-4b66-8cd0-91b1968f3694@em9g2000vbb.googlegroups.com>,
   Christopher Bazley <cs99cjb@gmail.com> wrote:
> The deleted_next_node() function manipulates the offset_to_next_item
> directly by subtracting 1 from it! This implies that the values
> returned by OS_GBPB in R4 must increase monotonically, otherwise
> subtraction would make no sense.

I believe it does for FSs like ADFS. One of the reasons I had to fix
up various DrWimp apps such as Labella and Calibre was that they made
just that assumption, and it broke nastily on Fat32FS, on which the
values of offset returned are very definitely not incrementing by 1
for each object.

-- 
Chris Johnson

[toc] | [prev] | [next] | [standalone]

#1489

I should add that OS_GBPB 9 is similar.

-- 
Chris Johnson

[toc] | [prev] | [next] | [standalone]

#1494

Hi,

>
> I believe it does for FSs like ADFS. One of the reasons I had to fix
> up various DrWimp apps such as Labella and Calibre was that they made
> just that assumption, and it broke nastily on Fat32FS, on which the
> values of offset returned are very definitely not incrementing by 1
> for each object.

For performance reasons Fat32fs does indeed return R4 incrementing
by 256 for each file.
In the source code provided (wimp.c.fs) you will find the following:

/*
Ok, so we enable this and take the potential hit on the shift-drag
performance....

Explanation of the problem:
On filecore directories there is a one-to-one relationship between the
number returned in
R4 and the number of files in the directory for the
FSEntry_Func(14,15,19) calls.
On Fat media the variable length filename uses additional file entry
blocks as needed.
This means that there is not a one-to-one relationship between the
number of files and the
qty of blocks used. So for speed I return the directory position in R4
rather than the
number of files found. This allows the next call to instantly continue
from where the
previous one left off. If I return the qty of files found in R4 then
the next call has
to scan through the directory all over again to count the files. This
is *very* slow.

When the Filer scans through the directory deleting files it
decrements R4 by one for
each file deleted. However on FAT media the file is only marked as
deleted and the entry
is not removed from the directory, hence R4 needs to remain the same.

So the fiddle that I have used here is to return in R4 the number
shifted left 8 places
and 0x80 added. This means that if the Filer alters R4 by a small
amount it will not
change the upper 24 bits.

Other software that expects to be able to use R4 to achieve random
access to the directory
listing will fail.

*/

Jeff

[toc] | [prev] | [next] | [standalone]

#1495

Hi Jeff

Thanks for the very clear details on Fat32fs.

Chris...

-- 
Chris Johnson

[toc] | [prev] | [next] | [standalone]

#1502

In message <ba7532b4-82ff-418c-9f3e-96e7083ccbba@w5g2000vbv.googlegroups.com>
 on 12 Mar 2012 jeff  wrote:

> When the Filer scans through the directory deleting files it decrements R4
> by one for each file deleted. However on FAT media the file is only marked
> as deleted and the entry is not removed from the directory, hence R4 needs
> to remain the same.
> 
> So the fiddle that I have used here is to return in R4 the number shifted
> left 8 places and 0x80 added. This means that if the Filer alters R4 by a
> small amount it will not change the upper 24 bits.

That's a nice solution, and I clearly ought to adopt something similar if I
ever release a new version of CPMFS.  I wonder whether DOSFS employs a
similar trick.

You're relying here on FilerAction never operating on more than 256 objects
at once, but Chris Bazley's reading of the source code suggests 20 at most is
the maximum.

If FilerAction is not going to be fixed, then it is essential that filing
system authors are made aware of these constraints and (mis-)uses of R4.  PRM
2 says nothing to make you suppose you'd have to deal with situations like
this.

How did you work out what to do, by the way?  Did you get strange things
happening and have to come up with the fix?

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1503

Hi,

> How did you work out what to do, by the way?  Did you get strange things
> happening and have to come up with the fix?

Yes, very strange things happening. It would try to delete a file that
was still
being copied (if I remember correctly). Or it would copy a file twice.
Because of this I tend to avoid Shift-dragging files off FAT media (ie
moving)
and just do a standard copy and then delete afterwards if the copy
worked.

Jeff

[toc] | [prev] | [next] | [standalone]

#1477

On 06/03/2012 22:33, Christopher Bazley wrote:
> I am thinking about moving some very generic code that is shared
> between several of my programs into a C library. The code in question
> uses OS_GBPB 12 recursively to enumerate all of the entries in a
> specified directory and its subdirectories (depth-first search of the
> directory tree).

[Snip API]

Why not start with OSLib to do the SWI calling, and just return a 
list/tree of the predefined structures?

> My question is: How long is it safe to retain the continuation value
> returned in R4 by SWI OS_GBPB 12? Can I retain it across calls to SWI
> Wimp_Poll or Wimp_PollIdle, then feed it back into the same SWI?

I wouldn't rely on any filing system state over calls to Wimp_Poll. 
Particularly as you are returning the results from what may be a 
transverse of a significant amount of the filing system, giving much 
wider scope for something else to change it.

> Obviously my C library won't know anything about whether the Wimp has
> been polled between calls to its DirIterator_advance() function, so
> the only safe thing to do would be to cache the entire contents of
> every directory as soon as I discover it. Given that my code would
> have to guess the initial buffer size and OS_GBPB doesn't guarantee to
> return as many directory entries as requested by the caller, that
> could take many SWI calls and a lot of memory for every branch of a
> deep directory tree.

You either have to do the entire traverse in one go, which may stop 
multi tasking on a large tree, or iterate through OS_GBPB 12 calls on 
each directory before calling poll. You'll have to gracefully handle the 
case where the data is stale from modifications to the OS, by going back 
up the tree.

---druck

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web