idea for an os fat setup

[ninjarider]

im working on an os and thought of something and i was wondering the efectiveness of it. how effective would it be for the bootloader or the os to load the filenames, location, an sizes into memory. i now for sure that it would speed up search speed.

[sluggy]

Later versions of windows already do that - it's called the Indexing Service, and it is turned off on my machine because it can be a real PITA at times - like when trying to build an ASP.Net application but none of the temporary dlls can be overwritten because the indexing service is busy cataloguing them.

[MichaelW]

Storing the directory information in memory would speed up directory searches, but file access involves more than just directory searches. IIRC DOS used to store a copy of the FAT in memory to speed up access to the FAT and, indirectly, to the file DATA. The basic idea is simple enough, but implementing it would be complicated by the need to keep the memory and disk copies in sync, and the need to make it work on systems where the memory could not reasonably hold all of the necessary data. I think a disk cache would be a more reasonable solution.

[Tedd]

It's a good diea to do this for the current directory at least.
If you keep a buffer for the entries in the current directory then finding a file/directory is pretty fast. And then when you change directory, you just load it into the buffer on top of the previous one.
I've done this in a boot loader and it works out fine.
For accessing files you also need to get the cluster information from the file-allocation table, which only needs to be laoded once. But obviously for large disks, it may take up a fair amount of memory. (For floppies it's fine.)

[ninjarider]

what kind of information would be a good idea to keep track of. i was just figureing on the basic name maybe sticking to the dos 8.3 file name system, the file size, and the location on the hard drive. and yeah with a 300 gig drive i dont think i could index the hard drive.

was able to pull a floppy image and view it as a text file and i think its interesting how it looks. dont know what it all means yet. :U
got that makes me sound like a geek.

[MichaelW]

Such a simple file system could work, without the file fragmentation problems typical of FAT file systems, but as files were resized/deleted/added the amount of wasted space would steadily increase.

http://en.wikipedia.org/wiki/File_Allocation_Table

[Tedd]

If you look at the actual format for FAT volumes - the information stored in a directory includes filename, filesize, attributes, date-time, and start cluster. Which is more than you need for finding and loading files. So you get everything you need from simply loading the contents of a directory.
In a bootloader you need to keep the code as tight as possible, so simply loading an entire directory is simpler than picking out the bits you only need. Each directory entry is only 32 bytes, so you wouldn't be saving a whole lot by extracting the essentials; except in the case of the os implementation, but in that case you'll probably want the extra information anyway.
Anyway, the bare minimum for a file-system would have to be filename and starting sector. This assumes that files are stored serially (in one piece, no fragmentation) and there's some way for finding the end of the file. Adding filesize would probably be a better option, plus some kind of indication for directories if you want to use them (why not?) which could either be an attributes byte, or do something special with the filename (eg. all filenames beginning with @ are directories, and normal files cannot start with @). Date and time and other information are useful, but not essential to the working of the filesystem.

[Mark Jones]

What about using SQLITE to maintain a run-time FAT table (buffer) in RAM? Then periodically service changes to the table? (Sort-of like super file buffering?) Prolly talkin' out my arse here... :lol