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

Groups > comp.sys.acorn.programmer > #1501

Re: OS_GBPB 12 in a Wimp task

Show all headers | View raw

In message <almarsoft.6587021169203963779@news.orange.fr>
 on 11 Mar 2012 Rick Murray  wrote:
 
> 1. Tweak FilerAction to remember past results of R4 and not assume 
> what future should be (other than as specified in the call)
> Or:
> 2. Amend the documentation to state that this behaviour happens.
> 
> The second is option is heinous. The first is really non-optimal but 
> at least more logical than subtracting one.
> 
> The second option *could* be dealt with by some filing systems - like 
> the poster who used R4 as an offset, simply take R4 and multiply by 
> 32 (well, MOV with LSL) to turn the number into the offset desired.

In the case of CP/M discs (again, merely an example, as I realise they're
little used) just multiplying by 32 is not sufficient.  Like FAT format
discs, CP/M's directories have a number of slots to describe files, and if a
file is deleted, the slot just marked with a value to signify it can be
reused.

FilerAction currently expects R4 to increase from 0 to 1, 2, 3, 4, 5 ..., -1
and subtracts one from the value to go back a step.

Imagine you had the following set of directory entries:

File1
File2
DELETED
File3
DELETED
File4
File5

To keep FilerAction happy it seems to me that you need to return R4=3 when
you return the details for File3, and R4=4 when returning details for File4. 
But suppose before the next call to OS_GBPB that another application creates
an additional file in the directory.  The filing system would probably be
implemented to make use of the first DELETED slot, in which case, any caller
passing in R4=3 would get File3 again!  The filing system cannot remember
that the caller is expecting File4 next and adjust itself internally, as
calls to OS_GBPB have no context other than R4.  I suppose you might do
something very fiddly, and use the top 16 bits of R4 to give some context to
the filing system, which could then internally adjust the meaning of the rest
of R4 for that caller through some redirection table, but that's
nightmarish, and how does the filing system know when to throw away that
redirection?  Callers are not obliged to read the whole directory till R4 is
returned as -1.

So for CP/M and FAT it's simply impractical to implement R4 as an index of
the currently active directory slots, as files can get inserted.  Indeed, I'm
not sure this is really practical in FileCore format either, as files can be
inserted because of the way FileCore keeps things in alphabetical order.  But
perhaps FilerAction is using its internal knowledge of FileCore to cope with
this?  The problem is that it cannot have internal knowledge of all filing
systems.

It is quite conceivable that a filing system might be implemented where the
R4 value which is returned is a pointer to an internal structure where more
complicated information is kept than can be fitted into a 32-bit word.  With
such a filing system, on entry with R4=0 the filing system would commence the
traversal of the directory, create the structure and return the pointer in
R4.  On subsequent calls it would return file information, and return the
*same* value in R4.  Finally, R4 would be returned with -1.

I cannot see how other filing systems, in general, could be rewritten to work
with FilerAction's current needs without imposing dreadful constraints on
filing system authors.

So I suppose the question is, in what circumstances is FilerAction doing this
arithmetic on R4?  It must think a file has been removed from earlier in the
directory for it to need to go back a step.  Does this occur during Move and
Delete operations, then?  Chris Johnson mentions SyncDiscs.  Copy operations
might be unaffected, but wipe might run into trouble if there were more than
twenty files to wipe from a FAT32 disc at a time.

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 in
turn.  I can't see any other robust way out of it.

-- 
Matthew Phillips
Durham

Back to comp.sys.acorn.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web