There is already a huge body of literature about FSes. The potential scope is vary large.

What do you need from your FS?

Do you need advanced features like ... Journaling? De-duplication? Redundancy? Versioning? Distributed? Etc.

If you just want simple file storage then it would probably be much easier to use basic FAT and be compatible with with all the external tools that can already deal with it. That way you can take advantage of other work without having to reinvent everything.

No. All I want is a simple file system with just a simple structre, and nothing fancy. I only want files and folders and their creation dates and modification dates stored on the disk, and none of the other fancy stuff.

No.
The LFN extension merely changed the 32 byte directory entry so that multiple directory entries could be used to
accommodate the LFN. The FAT directory entry which contains the meta data has the three time stamps. The
introduction of the modified and accessed times coincides with the introduction of LFN, however with or without LFN
the current FAT specification contains all three.
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Directory_entry

Well, I can't figure out how to map the files in fasm, and i just can't do a:
DW (file_start/512)
I am still working on a GrapeFS disk image creator in python, and it should have the ability to write a boot sector, and inject files, extrect files, and get the list of files, create directorys, and modify directorys.

LFN should have just been a new file system, because if you read the filenames in dos, it will give you a whole bunch of directorys, and not the whole filenames. I have tried that, and that just happened. Microsoft should have released some product called "LFN Extensions For MS-DOS"

... but to build our system, we need to make a disk image maker, so we need to work on that first.

The complete disk image, including a file system and the files can be written and assembled in FASM (no image maker required).

Why do that, when you could make a disk image creator, and later, I will use my operating system for my daily driver, so I would port virtualbox to it, and then make a build script that would use my disk image creator(ported to my os) to make a small disk image(like a 32-mb hdd file), with the GrapeFS filesystem, and that's how I would use it. I want my whole OS to be self-hosting.

LFN should have just been a new file system, because if you read the filenames in dos, it will give you a whole bunch of directorys, and not the whole filenames. I have tried that, and that just happened. Microsoft should have released some product called "LFN Extensions For MS-DOS"

IIRC, it (also) uses "volume" bit, so it shouldn't be found by normal findfirst, etc.

But did you really want an incompatible file system? Sometimes it's better to be compatible, even with kludgy workarounds. Then again, patents often destroy interoperability, so THAT I don't even pretend to understand. Patents are dumb, and we should've probably had a p.d. ext2 TSR driver. But no one cared (sigh). At least all VFAT patents have "probably" expired by now (sheesh).

Anyways, they had an improved file system (for OS/2) called HPFS. Not sure why that was never backported to DOS nor why it was quickly dropped after initial NT 3.1 release. There are partial third-party drivers for DOS, but it never was well-supported.

What you're thinking of is probably a TSR like DOSLFN. Not sure why MS didn't write one, but again, it's probably pointless when they want everyone to "upgrade" to Win9x GUI or "new technology" anyways. They probably didn't want to cannibalize their existing products.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum