It appears I might have confused rel files with direct access files. But my point is mostly in tact. By standard file allocation table, I meant one that was used for all files. It would have removed the requirement for file types completely. The storage requirements on disk would be lower as something like FAT replaces the BAM + sector links The problem is the RAM to store the entire FAT. On 21/07/2018 22:58, afachat@gmx.de wrote: > On Samstag, 21. Juli 2018 22:25:55 CEST smf wrote: >> On 21/07/2018 18:35, André Fachat wrote: >>> REL files are complicated and the implementation is rather buggy, also >>> depending on the DOS version. >>> >>> You cannot sequentially read the whole file as after the first record >>> read there comes an EOF already. >> REL files aren't complicated, they aren't complicated enough. >> >> Instead of implementing a standard file allocation table on disk and in >> ram, they let you use your own scheme. > Whatever a "standard file allocation table" means. There are so many different > file systems with different types of allocation mechanisms. > > In fact the DOS REL file implementation mixes the Commodore linked block chain > with the "standard" filesystem mechanisms (as e.g. seen in Linux's ext2) using > a bitmask (BAM) to find unused blocks and indirect blocks (side sectors) to > implement a seek functionality. The larger (8250/1001 DOS 2.7) drives even > implement double indirect blocks (super-side-sectors). > (see for example https://en.wikipedia.org/wiki/Inode_pointer_structure ) > >> I worked somewhere that had developed sales ledger, order processing and >> payroll packages for commodore PET using REL files. > I am not saying you cannot work around the bugs in the DOS REL file > implementations. But you had to take care about allocating the REL file at the > very beginning as dynamically extending was buggy, and some file sizes (max. > record numbers) had problems too IIRC from implementing my own REL file code in > C and comparing outcomes to equivalent DOS outcomes. > >> While it would have been nice if the drives had supported seeking, it >> would have pushed the price up due to needing more RAM. > REL files implement an almost perfect seek mechanism with the P(osition) > command, just with record number and position in record instead of linear > address. The complication comes from the DOS "feature" to send an EOF at the > end of the record. > > André > >Received on 2018-07-22 11:00:04
Archive generated by hypermail 2.2.0.