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

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

OS_GBPB 9 - Read filenames from directory

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

Contents

  OS_GBPB 9 - Read filenames from directory Martin <News03@avisoft.f9.co.uk> - 2011-09-25 17:04 +0100
    Re: OS_GBPB 9 - Read filenames from directory Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-09-25 20:18 +0200
    Re: OS_GBPB 9 - Read filenames from directory Terminal Crazy <Terminal_Crazy@sand-hill.freeserve.co.uk> - 2011-09-25 20:14 +0100
      Re: OS_GBPB 9 - Read filenames from directory jeff <jeffrey.a.doggett@gmail.com> - 2011-09-26 00:35 -0700
    Re: OS_GBPB 9 - Read filenames from directory "Ste (news)" <steve@revi11.plus.com> - 2011-09-28 15:25 +0100
      Re: OS_GBPB 9 - Read filenames from directory Vince M Hudd <vinceh@softrock.co.uk> - 2011-09-29 11:34 +0100
        Re: OS_GBPB 9 - Read filenames from directory "Ste (news)" <steve@revi11.plus.com> - 2011-09-29 12:39 +0100
          Re: OS_GBPB 9 - Read filenames from directory jgharston <jgh@arcade.demon.co.uk> - 2011-10-09 16:23 -0700

#765 — OS_GBPB 9 - Read filenames from directory

The SWI OS_GBPB,9-12 can be used for reading a list of file names from a
directory. The PRM page 2-70 makes no mention of the sequence in which
the files are returned, so it must presumably be assumed that they will
be in an indeterminate sequence.

However, it appears that the sequence is normally filename in all cases I
have been able to investigate, EXCEPT when using HostFS with VRPC, and
the files are actually on a FAT (not NTFS) formatted disc. In this case I
think that the sequence is the order in which the file was added to that
directory.

Incidentally, the command *Info <directory>.* appears to list files in
the same order as given by GBPB.

I write this note for two reasons:

1.  I maintain a program (not written by me) which uses GBPB to read
filenames AND it assumes a filename sequence. Indeed, it can go wrong if
they are not in filename sequence! I am assuming that this is a problem
with the program and not VRPC/HostFS, but before I change it I would be
interested to hear from anyone who cares to comment on, correct, or add
to my observations.

2.  To warn others using OS_GBPB that a filename sequence should NOT be
assumed!

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

[toc] | [next] | [standalone]

#767

On 25/09/2011 18:04, Martin wrote:

> 1.  I maintain a program (not written by me) which uses GBPB to read
> filenames AND it assumes a filename sequence.  Indeed, it can go wrong if
> they are not in filename sequence! I am assuming that this is a problem
> with the program and not VRPC/HostFS, but before I change it I would be
> interested to hear from anyone who cares to comment on, correct, or add
> to my observations.

I suspect GBPB simply returns the data "as provided by the filing 
system", and it is the filing system itself maintaining the directory in 
good order, instead of being lazy toads and just keeping it in 
added-to-directory order <cough>microsoft</cough>.

An interesting thought would be to try on non-FileCore systems (DOS 
disc, CD ROM (maybe?), Econet... do we have a Unix NFS filing system?) 
to see what order is returned.

Assuming a filename sequence in the program? Naughty! A crappy bubble 
sort wouldn't take any time at all for a little list of files...


Best wishes,

Rick.

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

#768

In article <5218550b41News03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> However, it appears that the sequence is normally filename in all cases I
> have been able to investigate, EXCEPT when using HostFS with VRPC, and
> the files are actually on a FAT (not NTFS) formatted disc. In this case I
> think that the sequence is the order in which the file was added to that
> directory.

I don't think there is any guarantee to the order. I'd wrongly assumed it
was ordered as per the filer view.   LanMan98 (from WinXP & Netgear Stora) 
& Sunfish (Ubuntu ext3) don't supply data in a sorted order. This played
havoc with my recursive enumerator. I have now resorted to sorting any
retuned list.
Had i realised this I might have written it differently...

-- 
Terminal_Crazy

Mitch - 1995 Z28 LT1 M6          terminal_crazy@sand-hill.freeserve.co.uk
Lancashire England          http://www.sand-hill.freeserve.co.uk/terminal_crazy/

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

#769

Hi,

>> I suspect GBPB simply returns the data "as provided by the filing
>> system", and it is the filing system itself maintaining the directory in
>> good order, instead of being lazy toads and just keeping it in
>> added-to-directory order <cough>microsoft</cough>.

Fat32fs also returns the files in added-to-directory order.
However a deleted file in FAT is left in the directory and is skipped
over automatically. The next file saved goes into that slot if the
filename length will fit.
These gaps cause a non-linearity in the returned value in (it think)
R4. This causes all sorts of problems for applications that think that
they can move the value of R4 by one to get the previous file.
Especially the Filer copy when moving files.

Jeff

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

#791

In article <5218550b41News03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> The SWI OS_GBPB,9-12 can be used for reading a list of file names from a
> directory. The PRM page 2-70 makes no mention of the sequence in which
> the files are returned, so it must presumably be assumed that they will
> be in an indeterminate sequence.

Correct. The objects are returned in whatever order the underlying file
system feels like. For FileCore-based file systems, this happens to be
alphabetical (ASCII) order. For network file systems (LanMan, NFS, etc) and
others (HostFS, etc) you'll probably get them in some other order.

This is a PITA, because you need to make a number of calls to GBPB (if
you're iterating over everything) and add all of the objects to a list which
you then have to sort later. It would've been nice if the OS presented a
call to do that for you, instead of umpteen developers re-inventing that
wheel over the years...

Ta,

Steve

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

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

#802

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

[...]

> This is a PITA, because you need to make a number of calls to GBPB (if
> you're iterating over everything) and add all of the objects to a list
> which you then have to sort later. It would've been nice if the OS
> presented a call to do that for you, instead of umpteen developers
> re-inventing that wheel over the years...

I take it you mean the whole thing - generate the list *and* sort it?
Because I don't think it's a whole heap (hohoho) of effort to carry out the
latter task. ;)

-- 
Soft Rock Software:                   http://www.softrock.co.uk
Vince M Hudd:                         http://misc.vinceh.com/about-vinceh/
RISCOSitory:                          http://www.riscository.com

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

#803

In article <mpro.lsa5dg001nvg803vg.vinceh@softrock.co.uk>,
   Vince M Hudd <vinceh@softrock.co.uk> wrote:
> I take it you mean the whole thing - generate the list *and* sort it?
> Because I don't think it's a whole heap (hohoho) of effort to carry out the
> latter task. ;)

Yes, a "Return me an array of all of the items in this directory, sorted
into alphabetical order". Even better would be an option to do the recursion
for you, too.

On the flip side, this does get into the realms of "that's what libraries
are for" and I can see with blocking I/O why the API tries to split the job
into multiple calls.

Steve

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

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

#863

Ste wrote:
> Yes, a "Return me an array of all of the items in this directory, sorted
> into alphabetical order". Even better would be an option to do the recursion
> for you, too.

It's actually quite fiddly for the callee to do the recursion, it's a
lot
easier for the caller to remember where in the directory structure
it is and just require the callee to scan the current level.

JGH

[toc] | [prev] | [standalone]

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

csiph-web