In message <116d532753...@hobbes.bass-software.com> on 4 Mar 2013 John Tytgat wrote:
> In message <dub120-ds7e48892a10433c7ca0983f0...@phx.gbl> > "Alan Buckley" <alan_...@hotmail.com> wrote: > > > From comments when I mentioned this bug on the ROOL forum it made me > > think Fat32FS does not increment the value as expected by the hack. > > It's very much possible that this wrong assumption is the cause of your > problem. > > However for enumeration purposes we're using 1 KByte buffer so you would > get a correct result for a 'modest' number of files in your cc > subdirectory. > > > Is there anybody who could look at to confirm my findings (and possibly > > fix) this? > > I'm not using FatFS32 myself but this can be very easily tested in > BASIC, just write a dir enum based on OS_GBPB (fetching at most 1 > element) and see what kind of offsets this generates. >From a discussion about this not long ago on comp.sys.acorn.<something> Jeff confirmed that Fat32FS may go up in steps of more than one. There was a failure case with a piece of software which attempted to go backwards a single step occasionally which he had allowed for in some cunning way at his end. There are other filing systems out there which do not go up in steps of one. CPMFS is another example, but I doubt anyone apart from me and J.G. Harston is using that, and we certainly wouldn't be compiling C off CP/M discs. CPMFS and Fat32FS have the same need because FAT shares some of the CP/M heritage. Basically, in a FAT directory each file or subdirectory entry takes 32 bytes. When a file is deleted, the first byte of the entry is marked to show that: the gap is not closed up. Also some entries are used not for files but for continuations of earlier entries to store long file names. The most straightforward thing for Fat32FS to return is thus an index into the list of directory entries, and while it will always ascend, it may skip some values on the way. The alternative, of ignoring deleted files in the numbering, would fail if a file earlier in the directory were deleted between calls to OS_GBPB. I think Jeff dealt with the software which subtracted one by spotting if the index pointed to an entry which was a deleted file or a filename continuation block and scanning backwards to find the previous genuine entry. I have a feeling it was FilerAction which was the culprit actually! Certainly the FilerAction module came up in the discussion. I have not looked at the unixlib code, but if it's just a matter of using a single 32-bit word (an off_t ?) to keep track of enumerating two directories independently via OS_GBPB there must be a solution which does not involve assuming an increase of one per file, even without going as far as scanning the whole directory at the outset. -- Matthew Phillips Durham _______________________________________________ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
