Hi,
Candy wrote:
I can only see a few very minor things:
- Empty directories can't exist, so how do you create a directory and a file in it, if the intermediate state doesn't exist?
I agree with JoeKayzA here - zero length files with a trailing slash would work fine, and we could make seperate directory entries a requirement to avoid the need to check if a directory becomes empty when a file is deleted.
In this case we'd need to check if the directory entry exists before creating a file in a directory, but this is normal for any file system. It'd use up some extra space in the "index area", but it does make much more sense - thanks for this JoeKayzA
Candy wrote:
- No timestamps. If the only place, transferrable mediums are places where time stamps are a very good thing. Helped my girlfriend figure out when a given document was written using them last night.
Timestamps would be easy to add, but deciding the format for them could be a little tricky - I prefer "signed 64 bit mS since 1/1/2000", but other OSs do it differently.
Candy wrote:
- Beforementioned space fragmentation. If you intend it to be used as semi-permanent storage for for instance photo's, it's a problem. The camera would have to defragment or use memory inefficiently.
Devices that use flash memory could copy data relatively quickly (as compared to floppies for example). The easiest way would be to shift all data when a file is deleted, but more complex methods could be implemented instead. If all files are the same size (likely for a digital camera) then a new file/photo would fit perfectly in the hole left by deleting a file/photo.
Candy wrote:
Also, those long file names are very uncommon iirc, you might just as well shrink them to 64byte entries leaving 40 bytes for the file name. Even that allows pretty long names. Although, second thought, if you include directory prefix, make them 128 byte, still leaving 104 bytes for it.
I agree - it'd be more efficient, and 104 bytes (or 103 characters) is still plenty long enough.
The other problem I'm seeing is appending data to files. It'd be better if the data area was at the start of the file system (just after the reserved sectors) growing upwards, with the index area at the end of the file system growing downwards.
Candy wrote:
Of course, concerning FAT I'm going to be the arse that just implements it and ignores the rest. Yes, that's a liability. No, I don't care.
I can afford to wait. My boot code uses raw disk sectors without any file system, and it'll take a while before I need to worry about sharing files with other OSs.
Other people aren't as fortunate, and IMHO it'd be nice if the world stopped relying on Microsoft's proprietory formats...
Cheers,
Brendan