Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.acorn.programmer > #5684
| Date | 2019-01-22 08:14 +0000 |
|---|---|
| From | Matthew Phillips <spam2011m@yahoo.co.uk> |
| Newsgroups | comp.sys.acorn.programmer |
| Subject | Re: Traversing a directory in BASIC... |
| Message-ID | <a7fa427a57.Matthew@sinenomine.freeserve.co.uk> (permalink) |
| References | <5551f8d2-bbd0-4d15-aa64-bc799be24414@googlegroups.com> <mpro.plpduj01xvpnf01pb.news@stevefryatt.org.uk> <1736875c-babb-4d19-88f7-6f6863d5da8d@googlegroups.com> <mpro.plphal02u95ej01pb.news@stevefryatt.org.uk> <da0a6ea9-9d73-4c78-bb8a-fffda39b63d9@googlegroups.com> |
In message <da0a6ea9-9d73-4c78-bb8a-fffda39b63d9@googlegroups.com> on 22 Jan 2019 usenet@garethlock.com wrote: > Just out of interest, what exactly would cause read% to return zero whilst > next% <> -1 I.e there are still entries to read... Curiosity... It depends entirely on the implementation of the underlying file system which may not be FileCore. You should also not assume that the value in F4 increases by one each time the information for a single file is read. Some applications come unstuck by making this assumption, which does not hold true for FAT32FS, for example. To give you an example of why a filing system might return no entries, let me introduce you to the CP/M disc format, for which I wrote CPMFS. The CP/M format was a predecessor of MSDOS and is the origin of the 8 + 3 (name + extension) style of filename that persisted until Windows 95. The directory on the disc is held in a block of a number of consecutive sectors. Each directory entry is 32 bytes long. The first 16 bytes contains a byte that can indicate the file is deleted, the filename, and a directory entry count. The following 16 bytes point to the sectors on the disc where the file is found. The way I implemented CPMFS, R4 corresponds to the directory entry to read next, so when you enter with R4 = 0 it reads the first entry. Suppose you ask for four to be read each time. On exit R4 will equal 4, then 8, then 12, and eventually will be set to -1 when there are no more to read. But it's possible that all the first four directory entries are for deleted files, in which case no results will be returned. Also, if a file is larger than 16K it will require more than one directory entry to record the allocated sectors, so any of the directory entries that handle the overflow will not be reported when reading the files via OS_GBPB. At least, that's one possible implementation. It's certainly how I handled what R4 meant, but it may be that I just looped round until I had read the number of objects requested in R3, and the exit value in R4 would have gone up by more than four in these cases. I can't remember. FAT32FS also implements R4 in a similar way. This means you cannot safely take 1 off R4 to step back by 1 in the directory listing. Another reason for returning zero in R3 might be if the filing system is waiting for a network device to respond and has had to time out to keep the machine responsive. -- Matthew Phillips Durham
Back to comp.sys.acorn.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Traversing a directory in BASIC... usenet@garethlock.com - 2019-01-21 13:48 -0800
Re: Traversing a directory in BASIC... Gerald Holdsworth <nospam@hollypops.co.uk> - 2019-01-21 22:18 +0000
Re: Traversing a directory in BASIC... Steve Fryatt <news@stevefryatt.org.uk> - 2019-01-21 22:44 +0000
Re: Traversing a directory in BASIC... usenet@garethlock.com - 2019-01-21 15:02 -0800
Re: Traversing a directory in BASIC... Steve Fryatt <news@stevefryatt.org.uk> - 2019-01-21 23:59 +0000
Re: Traversing a directory in BASIC... usenet@garethlock.com - 2019-01-21 18:12 -0800
Re: Traversing a directory in BASIC... Matthew Phillips <spam2011m@yahoo.co.uk> - 2019-01-22 08:14 +0000
Re: Traversing a directory in BASIC... Martin <News03@avisoft.f9.co.uk> - 2019-01-21 23:04 +0000
Re: Traversing a directory in BASIC... usenet@garethlock.com - 2019-01-21 15:53 -0800
Re: Traversing a directory in BASIC... Alan Adams <alan@adamshome.org.uk> - 2019-01-22 12:26 +0000
Re: Traversing a directory in BASIC... Martin <News03@avisoft.f9.co.uk> - 2019-01-22 16:30 +0000
Re: Traversing a directory in BASIC... jgh@mdfs.net - 2019-01-23 05:26 -0800
Re: Traversing a directory in BASIC... Alan Adams <alan@adamshome.org.uk> - 2019-01-23 15:01 +0000
Re: Traversing a directory in BASIC... David Higton <dave@davehigton.me.uk> - 2019-01-24 14:35 +0000
Re: Traversing a directory in BASIC... Richard Porter <dontusethis@address.uk.invalid> - 2019-01-27 23:33 +0000
csiph-web