Folder
47 views
Skip to first unread message
Ahmed
Jan 27, 2025, 8:30:08 AMJan 27
to MikeOS
Hi, is there a way to make folders in mikeos,
thanks
Michael Saunders
Jan 27, 2025, 8:31:18 AMJan 27
to Ahmed, MikeOS
The FAT12 driver in the codebase does not support directories.
Daniel Barry
Jan 27, 2025, 9:17:27 AMJan 27
to Michael Saunders, Ahmed, MikeOS
Hello Mike and Ahmed,
I wanted to test this as there is mixed information regarding directory support:
I wrote the following Bash script, but it does not behave at all as expected, allowing >12 character names and directories (tested in Ubuntu):
# Create test image
dd if=/dev/zero bs=512 count=2880 of=test.img
mkfs.vfat -F12 test.img
file test.img
# Mount image
sudo mkdir /media/$USER/test
# NOTE: This is hacky.
sudo chown $USER: /media/$USER/test
sudo mount -o loop test.img /media/$USER/test
sudo chmod -R 777 /media/$USER/test
# Test: Blank file
sudo touch /media/$USER/test/test.txt
ls -lah /media/$USER/test/
# Test: Long file (shouldn't be possible)
sudo touch /media/$USER/test/01234567890123456789
ls -lah /media/$USER/test/
# Test: Directory
sudo mkdir /media/$USER/test/dir
sudo touch /media/$USER/test/dir/testfile
ls -lah /media/$USER/test/
# Test remount (encase it is some cached weirdness)
sudo umount /media/$USER/test
sudo mount -o loop test.img /media/$USER/test
ls -lah /media/$USER/test/
# Clean-up
sudo umount /media/$USER/test
sudo rm -rf /media/$USER/test
dd if=/dev/zero bs=512 count=2880 of=test.img
mkfs.vfat -F12 test.img
file test.img
# Mount image
sudo mkdir /media/$USER/test
# NOTE: This is hacky.
sudo chown $USER: /media/$USER/test
sudo mount -o loop test.img /media/$USER/test
sudo chmod -R 777 /media/$USER/test
# Test: Blank file
sudo touch /media/$USER/test/test.txt
ls -lah /media/$USER/test/
# Test: Long file (shouldn't be possible)
sudo touch /media/$USER/test/01234567890123456789
ls -lah /media/$USER/test/
# Test: Directory
sudo mkdir /media/$USER/test/dir
sudo touch /media/$USER/test/dir/testfile
ls -lah /media/$USER/test/
# Test remount (encase it is some cached weirdness)
sudo umount /media/$USER/test
sudo mount -o loop test.img /media/$USER/test
ls -lah /media/$USER/test/
# Clean-up
sudo umount /media/$USER/test
sudo rm -rf /media/$USER/test
Example output (attention to the parts in bold):
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB, 1.4 MiB) copied, 0.00430911 s, 342 MB/s
mkfs.fat 4.2 (2021-01-31)
test.img: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", root entries 224, sectors 2880 (volumes <=32 MB), sectors/FAT 9, sectors/track 18, serial number 0x38ac9811, unlabeled, FAT (12 bit), followed by FAT
total 11K
drwxr-xr-x 2 root root 7.0K Jan 1 1970 .
drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
-rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
total 11K
drwxr-xr-x 2 root root 7.0K Jan 1 1970 .
drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
-rwxr-xr-x 1 root root 0 Jan 27 14:09 01234567890123456789
-rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
total 12K
drwxr-xr-x 3 root root 7.0K Jan 1 1970 .
drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
-rwxr-xr-x 1 root root 0 Jan 27 14:09 01234567890123456789
drwxr-xr-x 2 root root 512 Jan 27 14:09 dir
-rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
total 12K
drwxr-xr-x 3 root root 7.0K Jan 1 1970 .
drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
-rwxr-xr-x 1 root root 0 Jan 27 14:09 01234567890123456789
drwxr-xr-x 2 root root 512 Jan 27 14:09 dir
-rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
2880+0 records out
1474560 bytes (1.5 MB, 1.4 MiB) copied, 0.00430911 s, 342 MB/s
mkfs.fat 4.2 (2021-01-31)
test.img: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", root entries 224, sectors 2880 (volumes <=32 MB), sectors/FAT 9, sectors/track 18, serial number 0x38ac9811, unlabeled, FAT (12 bit), followed by FAT
total 11K
drwxr-xr-x 2 root root 7.0K Jan 1 1970 .
drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
-rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
total 11K
drwxr-xr-x 2 root root 7.0K Jan 1 1970 .
drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
-rwxr-xr-x 1 root root 0 Jan 27 14:09 01234567890123456789
-rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
total 12K
drwxr-xr-x 3 root root 7.0K Jan 1 1970 .
drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
-rwxr-xr-x 1 root root 0 Jan 27 14:09 01234567890123456789
drwxr-xr-x 2 root root 512 Jan 27 14:09 dir
-rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
total 12K
drwxr-xr-x 3 root root 7.0K Jan 1 1970 .
drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
-rwxr-xr-x 1 root root 0 Jan 27 14:09 01234567890123456789
drwxr-xr-x 2 root root 512 Jan 27 14:09 dir
-rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
I can only think that it is mounted incorrectly, that mkfs is bugged, or that I didn't understand the image being created.
Any thoughts are appreciated,
Dan
On Mon, Jan 27, 2025 at 1:31 PM Michael Saunders <oka...@gmail.com> wrote:
The FAT12 driver in the codebase does not support directories.
--
You received this message because you are subscribed to the Google Groups "MikeOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mikeos+un...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/mikeos/CACtjVkFpn3%2BbTYE%2BsWQ88ZummbhAfKV1X3AJCQgvSWwYcvmUwA%40mail.gmail.com.
Joshua Beck
Feb 7, 2025, 5:15:21 AMFeb 7
to MikeOS
This is not a bad mount option or a bug.
Your modern operating system is creating LFN entries.
Supplementary filename data that's only visible to operating systems that support the VFAT extension.
Put simply, the longer filename is split into pieces, and put into fake file entries marked as hidden system files.
Since VFAT is a hack on the FAT directory system, it's compatible with all versions of FAT including FAT12.
If you create a file named "mylongfilename.txt", your modern operating system will create a FAT file entry for a shortened version of the name.
A name like "MYLONG~1.TXT" based off the original filename, but compatible with all the standard FAT rules.
Then it will create one or more LFN entries to make the supplementary filename that only VFAT-compatible operating systems will be able to see.
Hobby (or older) operating systems will still be able to see/read/write the file through its "real" filename (i.e. MYLONG~1.TXT).
Modern operating systems will search for the supplementary name.
If they find one they'll use that name, otherwise they'll use the file's real name.
So that's all well and good, but what if you want to avoid creating LFNs?
What if you just want a regular FAT file entry that's the same for your hobby and modern OS with no fancy tricky?
Well it's quite simple really: just give a standard 8.3 filename.
That's it. Your modern operating system will not create an LFN if there's no need (if fact it's illegal in the spec).
Just remember a few simple rules:
- Eight characters or less for the name.
- Three letters for the extension.
- A dot between the name and extension.
- Capital letters and numbers only, no spaces or symbols.
- And absolutely no non-ASCII characters.
So is the paper in your second source wrong?
No! It's just simplified. It doesn't include all the modern features.
What about directories?
Hobby operating systems like MikeOS don't support them (and some very ancient versions of DOS).
But directories are definitely supported by FAT12 and have been since its early iterations.
I hope that answers your question! 🙂
Joshua Beck
Daniel Barry
Feb 7, 2025, 6:27:35 AMFeb 7
to Joshua Beck, MikeOS
Hi Joshua,
> Since VFAT is a hack on the FAT directory system, it's compatible with all versions of FAT including FAT12.
That certainly explains it!
> So that's all well and good, but what if you want to avoid creating LFNs?
> What if you just want a regular FAT file entry that's the same for your hobby and modern OS with no fancy tricky?
>
> Well it's quite simple really: just give a standard 8.3 filename.
>
> That's it. Your modern operating system will not create an LFN if there's no need (if fact it's illegal in the spec).
You learn something new every day, thank you!
> But directories are definitely supported by FAT12 and have been since its early iterations.
Ah okay, that makes sense. There is a lot of mixed messaging out there.
Do you happen to know of a FAT12 (no VFAT) driver supporting directories? I did take a look and couldn't see anything clearly implemented or describing how to implement it.
Would be interesting for example to see what the limits are for number of files in a directory, number of directories, depth of directories, etc.
Kind Regards,
Dan
To view this discussion, visit https://groups.google.com/d/msgid/mikeos/c0ceb318-ed7c-41b2-a4fa-6ba5353c4586n%40googlegroups.com.
Joshua Beck
Feb 7, 2025, 3:55:41 PMFeb 7
to MikeOS
> Do you happen to know of a FAT12 (no VFAT) driver supporting directories?
I'd start by checking the old MSDOS directory source code.
There's a lot of Hobby OS code of various qualities floating around, but this is what Microsoft used.
Alternatively there's the newer MS-DOS 4.0 directory source code.
It's easier to read with a few more comments.
> Would be interesting for example to see what the limits are for number of files in a directory, number of directories, depth of directories, etc.
Take a look the FAT Filesystem Specification.
The explanations and examples are quite good.
It seems the be the source of a lot of the information in the PDF you linked.
Of the name length, Microsoft has this to say:
Short names are limited to 8 characters followed by an optional period (.) and extension of up to 3 characters.
The total path length of a short name cannot exceed 80 characters (64 char path + 3 drive letter + 12 for 8.3 name + NUL) including the trailing NUL.
While I'm not aware of any limits to the directory depth, you probably shouldn't exceed seven levels.
Eight characters plus a slash would be (8+1)*7=63
But it's rare you'd actually need that many levels in a simple hobby operating system anyway.
If you're loading off a floppy disk it's going to be sloooooow to load that many directories one by one to find file "A:\FOO\BAR\STUFF\ETC\DATA\FILE.TXT".
You probably want to cache at least the "current" directory.
As for the number of files...
...well again there's no hard limit.
FAT directories are just files with the directory flag set and the length set to zero.
It depends on how large the directory "file" is!
The (semi) official limit is the 65535, the limits of a 16-bit variable since there's a lot of 16-bit FAT code in operation.
In practice, many DOS versions do not support more than 512.
A lot of hobby systems often have trouble with directories containing more than say, a hundred files.
It certainly doesn't help if an LFN creates many hidden directory entries.
It's up to you if you want to set a hard limit for your operating system for say... memory constraints...
When a directory is created, a file with the ATTR_DIRECTORY bit set in its DIR_Attr field, you set its DIR_FileSize to 0. DIR_FileSize is not used and is always 0 on a file with the ATTR_DIRECTORY attribute (directories are sized by simply following their cluster chains to the EOC mark). One cluster is allocated to the directory (unless it is the root directory on a FAT16/FAT12 volume), and you set DIR_FstClusLO and DIR_FstClusHI to that cluster number and place an EOC mark in that clusters entry in the FAT. Next, you initialize all bytes of that cluster to 0. If the directory is the root directory, you are done (there are no dot or dotdot entries in the root directory). If the directory is not the root directory, you need to create two special entries in the first two 32-byte directory entries of the directory (the first two 32 byte entries in the data region of the cluster you just allocated).
The first directory entry has DIR_Name set to:
“. ”The second has DIR_Name set to:
“.. ”To sum it up:
- Create a directory by making a file with the directory flag set (length zero).
- Fill it with FAT file entries (including possible subdirectories).
- Parse your directories just like the root directory.
- Start your directory small, with a single cluster, and grow as needed.
- Remember you can support sixteen files per cluster (512/32=16).
- The first two files are always directory entries called "." and "..", pointing to the current directory and the parent respectively.
I hope this helps,
Joshua Beck
Dan
Feb 9, 2025, 3:01:07 PMFeb 9
to mik...@googlegroups.com
Thank you very much!
Kind Regards,
Dan
On 07/02/2025 20:55, Joshua Beck wrote:
> > Do you happen to know of a FAT12 (no VFAT) driver supporting directories?
>
> I'd start by checking the old MSDOS directory source code.
> <https://github.com/microsoft/MS-DOS/blob/main/v2.0%2Fsource%2FDIRCALL.ASM>
> (.) and extension of up to 3 characters./
>
> / The total path length of a short name cannot exceed 80 characters (64
>
> /The first directory entry has DIR_Name set to: /
>
> /“/. ”
>
> /The second has DIR_Name set to: /
>
> /“.. ”/
>
> To sum it up:
>
> * Create a directory by making a file with the directory flag set
> (length zero).
> * Fill it with FAT file entries (including possible subdirectories).
> * Parse your directories just like the root directory.
> * Start your directory small, with a single cluster, and grow as needed.
> * Remember you can support sixteen files per cluster (512/32=16).
> * The first two files are always directory entries called "." and
>
> If you create a file named "/mylongfilename.txt/", your modern
> * Three letters for the extension.
> * A dot between the name and extension.
> * Capital letters and numbers only, no spaces or symbols.
> * And absolutely no non-ASCII characters.
>
>
> _What about directories?_
> 0x38ac9811, unlabeled, *FAT (12 bit)*, followed by FAT
Kind Regards,
Dan
On 07/02/2025 20:55, Joshua Beck wrote:
> > Do you happen to know of a FAT12 (no VFAT) driver supporting directories?
>
> I'd start by checking the old MSDOS directory source code.
>
> There's a lot of Hobby OS code of various qualities floating around, but
> this is what Microsoft used.
>
> Alternatively there's the newer MS-DOS 4.0 directory source code.
> <https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/DOS/DIRCALL.ASM>
> There's a lot of Hobby OS code of various qualities floating around, but
> this is what Microsoft used.
>
> Alternatively there's the newer MS-DOS 4.0 directory source code.
>
> It's easier to read with a few more comments.
>
>
> > Would be interesting for example to see what the limits are for
> number of files in a directory, number of directories, depth of
> directories, etc.
>
> Take a look the FAT Filesystem Specification
> <http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc>.
> It's easier to read with a few more comments.
>
>
> > Would be interesting for example to see what the limits are for
> number of files in a directory, number of directories, depth of
> directories, etc.
>
> Take a look the FAT Filesystem Specification
>
> The explanations and examples are quite good.
>
> It seems the be the source of a lot of the information in the PDF you
> linked.
>
> Of the name length, Microsoft has this to say:
>
> /Short names are limited to 8 characters followed by an optional period
> The explanations and examples are quite good.
>
> It seems the be the source of a lot of the information in the PDF you
> linked.
>
> Of the name length, Microsoft has this to say:
>
> (.) and extension of up to 3 characters./
>
> / The total path length of a short name cannot exceed 80 characters (64
> char path + 3 drive letter + 12 for 8.3 name + NUL) including the
> trailing NUL. /
>
>
> While I'm not aware of any limits to the directory depth, you probably
> shouldn't exceed seven levels.
> Eight characters plus a slash would be (8+1)*7=63
> But it's rare you'd actually need that many levels in a simple hobby
> operating system anyway.
>
> If you're loading off a floppy disk it's going to be /sloooooow/ to load
>
> While I'm not aware of any limits to the directory depth, you probably
> shouldn't exceed seven levels.
> Eight characters plus a slash would be (8+1)*7=63
> But it's rare you'd actually need that many levels in a simple hobby
> operating system anyway.
>
> that many directories one by one to find file
> "A:\FOO\BAR\STUFF\ETC\DATA\FILE.TXT".
> You probably want to cache at least the "current" directory.
>
> _As for the number of files..._
> "A:\FOO\BAR\STUFF\ETC\DATA\FILE.TXT".
> You probably want to cache at least the "current" directory.
>
> ...well again there's no hard limit.
> FAT directories are just files with the directory flag set and the
> length set to zero.
> It depends on how large the directory "file" is!
> The (semi) official limit is the *65535*, the limits of a 16-bit
> FAT directories are just files with the directory flag set and the
> length set to zero.
> It depends on how large the directory "file" is!
> variable since there's a lot of 16-bit FAT code in operation.
>
> In practice, many DOS versions do not support more than *512*.
>
> A lot of hobby systems often have trouble with directories containing
> more than say, /a hundred files/.
> It certainly doesn't help if an LFN creates many hidden directory entries.
> It's up to you if you want to set a hard limit for your operating system
> for say... /memory constraints/...
> It's up to you if you want to set a hard limit for your operating system
>
> The spec has this to say on creating directories:
>
> /When a directory is created, a file with the ATTR_DIRECTORY bit set in
> The spec has this to say on creating directories:
>
> its DIR_Attr field, you set its DIR_FileSize to 0. DIR_FileSize is not
> used and is always 0 on a file with the ATTR_DIRECTORY attribute
> (directories are sized by simply following their cluster chains to the
> EOC mark). One cluster is allocated to the directory (unless it is the
> root directory on a FAT16/FAT12 volume), and you set DIR_FstClusLO and
> DIR_FstClusHI to that cluster number and place an EOC mark in that
> clusters entry in the FAT. Next, you initialize all bytes of that
> cluster to 0. If the directory is the root directory, you are done
> (there are no dot or dotdot entries in the root directory). If the
> directory is not the root directory, you need to create two special
> entries in the first two 32-byte directory entries of the directory (the
> first two 32 byte entries in the data region of the cluster you just
> allocated). /
> used and is always 0 on a file with the ATTR_DIRECTORY attribute
> (directories are sized by simply following their cluster chains to the
> EOC mark). One cluster is allocated to the directory (unless it is the
> root directory on a FAT16/FAT12 volume), and you set DIR_FstClusLO and
> DIR_FstClusHI to that cluster number and place an EOC mark in that
> clusters entry in the FAT. Next, you initialize all bytes of that
> cluster to 0. If the directory is the root directory, you are done
> (there are no dot or dotdot entries in the root directory). If the
> directory is not the root directory, you need to create two special
> entries in the first two 32-byte directory entries of the directory (the
> first two 32 byte entries in the data region of the cluster you just
>
> /The first directory entry has DIR_Name set to: /
>
> /“/. ”
>
> /The second has DIR_Name set to: /
>
> /“.. ”/
>
> To sum it up:
>
> * Create a directory by making a file with the directory flag set
> (length zero).
> * Fill it with FAT file entries (including possible subdirectories).
> * Parse your directories just like the root directory.
> * Start your directory small, with a single cluster, and grow as needed.
> * Remember you can support sixteen files per cluster (512/32=16).
> * The first two files are always directory entries called "." and
> "..", pointing to the current directory and the parent respectively.
>
>
> I hope this helps,
> Joshua Beck
>
> On Friday, 7 February 2025 at 21:57:35 UTC+10:30 danbarry wrote:
>
> Hi Joshua,
>
> > Since VFAT is a hack on the FAT directory system, it's compatible
> with all versions of FAT including FAT12.
>
> That certainly explains it!
>
> > So that's all well and good, but what if you want to avoid
> creating LFNs?
> > What if you just want a regular FAT file entry that's the same
> for your hobby and modern OS with no fancy tricky?
> >
> > Well it's quite simple really: just give a standard 8.3 filename.
> >
> > That's it. Your modern operating system will not create an LFN if
> there's no need (if fact it's illegal in the spec).
>
> You learn something new every day, thank you!
>
> > But directories *are definitely* supported by FAT12 and have been
>
>
> I hope this helps,
> Joshua Beck
>
> On Friday, 7 February 2025 at 21:57:35 UTC+10:30 danbarry wrote:
>
> Hi Joshua,
>
> > Since VFAT is a hack on the FAT directory system, it's compatible
> with all versions of FAT including FAT12.
>
> That certainly explains it!
>
> > So that's all well and good, but what if you want to avoid
> creating LFNs?
> > What if you just want a regular FAT file entry that's the same
> for your hobby and modern OS with no fancy tricky?
> >
> > Well it's quite simple really: just give a standard 8.3 filename.
> >
> > That's it. Your modern operating system will not create an LFN if
> there's no need (if fact it's illegal in the spec).
>
> You learn something new every day, thank you!
>
> since its early iterations.
>
> Ah okay, that makes sense. There is a lot of mixed messaging out there.
>
> Do you happen to know of a FAT12 (no VFAT) driver supporting
> directories? I did take a look and couldn't see anything clearly
> implemented or describing how to implement it.
>
> Would be interesting for example to see what the limits are for
> number of files in a directory, number of directories, depth of
> directories, etc.
>
> Kind Regards,
>
> Dan
>
> On Fri, Feb 7, 2025 at 10:15 AM Joshua Beck <joshua.b...@gmail.com>
> wrote:
>
> This is not a bad mount option or a bug.
>
> Your modern operating system is creatingLFN entries
> <https://wiki.osdev.org/FAT#Long_File_Names>.
>
> Ah okay, that makes sense. There is a lot of mixed messaging out there.
>
> Do you happen to know of a FAT12 (no VFAT) driver supporting
> directories? I did take a look and couldn't see anything clearly
> implemented or describing how to implement it.
>
> Would be interesting for example to see what the limits are for
> number of files in a directory, number of directories, depth of
> directories, etc.
>
> Kind Regards,
>
> Dan
>
> On Fri, Feb 7, 2025 at 10:15 AM Joshua Beck <joshua.b...@gmail.com>
> wrote:
>
> This is not a bad mount option or a bug.
>
> Your modern operating system is creatingLFN entries
> Supplementary filename data that's only visible to operating
> systems that support the VFAT extension.
> Put simply, the longer filename is split into pieces, and put
> into fake file entries marked as hidden system files.
>
> Since VFAT is a hack on the FAT directory system, it's
> compatible with all versions of FAT *including FAT12*.
> systems that support the VFAT extension.
> Put simply, the longer filename is split into pieces, and put
> into fake file entries marked as hidden system files.
>
> Since VFAT is a hack on the FAT directory system, it's
>
> If you create a file named "/mylongfilename.txt/", your modern
> operating system will create a FAT file entry for a shortened
> version of the name.
> A name like "/MYLONG~1.TXT/" based off the original filename,
> version of the name.
> but compatible with all the standard FAT rules.
> Then it will create one or more LFN entries to make the
> supplementary filename that only VFAT-compatible operating
> systems will be able to see.
>
> Hobby (or older) operating systems will still be able to
> see/read/write the file through its "real" filename (i.e.
> MYLONG~1.TXT).
> Modern operating systems will search for the supplementary name.
> If they find one they'll use that name, otherwise they'll use
> the file's real name.
>
> So that's all well and good, but what if you want to avoid
> creating LFNs?
> What if you just want a regular FAT file entry that's the same
> for your hobby and modern OS with no fancy tricky?
>
> Well it's quite simple really: just give a standard 8.3 filename.
>
> That's it. Your modern operating system will not create an LFN
> if there's no need (if fact it's illegal in the spec).
>
> Just remember a few simple rules:
>
> * Eight characters or less for the name.
> Then it will create one or more LFN entries to make the
> supplementary filename that only VFAT-compatible operating
> systems will be able to see.
>
> Hobby (or older) operating systems will still be able to
> see/read/write the file through its "real" filename (i.e.
> MYLONG~1.TXT).
> Modern operating systems will search for the supplementary name.
> If they find one they'll use that name, otherwise they'll use
> the file's real name.
>
> So that's all well and good, but what if you want to avoid
> creating LFNs?
> What if you just want a regular FAT file entry that's the same
> for your hobby and modern OS with no fancy tricky?
>
> Well it's quite simple really: just give a standard 8.3 filename.
>
> That's it. Your modern operating system will not create an LFN
> if there's no need (if fact it's illegal in the spec).
>
> Just remember a few simple rules:
>
> * Three letters for the extension.
> * A dot between the name and extension.
> * Capital letters and numbers only, no spaces or symbols.
> * And absolutely no non-ASCII characters.
>
> So is the paper in your second source wrong?
> No! *It's just simplified.* It doesn't include all the modern
> So is the paper in your second source wrong?
> features.
>
> See the FAT article on the OSDev wiki for further reading.
> <https://wiki.osdev.org/FAT>
>
> See the FAT article on the OSDev wiki for further reading.
>
>
> _What about directories?_
> Hobby operating systems like MikeOS don't support them (and some
> very ancient versions of DOS).
> But directories *are definitely* supported by FAT12 and have
> very ancient versions of DOS).
> been since its early iterations.
>
> I hope that answers your question! 🙂
>
> Joshua Beck
>
> On Tuesday, 28 January 2025 at 00:47:27 UTC+10:30 danbarry wrote:
>
> Hello Mike and Ahmed,
>
> I wanted to test this as there is mixed information
> regarding directory support:
>
> * https://forum.osdev.org/viewtopic.php?t=15888
> <https://forum.osdev.org/viewtopic.php?t=15888>
> * Page 8 here:
> https://www.eit.lth.se/fileadmin/eit/courses/eitn50/Literature/fat12_description.pdf <https://www.eit.lth.se/fileadmin/eit/courses/eitn50/Literature/fat12_description.pdf>
>
> I hope that answers your question! 🙂
>
> Joshua Beck
>
> On Tuesday, 28 January 2025 at 00:47:27 UTC+10:30 danbarry wrote:
>
> Hello Mike and Ahmed,
>
> I wanted to test this as there is mixed information
> regarding directory support:
>
> * https://forum.osdev.org/viewtopic.php?t=15888
> <https://forum.osdev.org/viewtopic.php?t=15888>
> * Page 8 here:
> total 11K
> drwxr-xr-x 2 root root 7.0K Jan 1 1970 .
> drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
> -rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
> total 11K
> drwxr-xr-x 2 root root 7.0K Jan 1 1970 .
> drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
> -rwxr-xr-x 1 root root 0 Jan 27 14:09 *01234567890123456789*
> drwxr-xr-x 2 root root 7.0K Jan 1 1970 .
> drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
> -rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
> total 11K
> drwxr-xr-x 2 root root 7.0K Jan 1 1970 .
> drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
> -rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
> total 12K
> drwxr-xr-x 3 root root 7.0K Jan 1 1970 .
> drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
> -rwxr-xr-x 1 root root 0 Jan 27 14:09 01234567890123456789
> drwxr-xr-x 2 root root 512 Jan 27 14:09 *dir*
> total 12K
> drwxr-xr-x 3 root root 7.0K Jan 1 1970 .
> drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
> -rwxr-xr-x 1 root root 0 Jan 27 14:09 01234567890123456789
> -rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
> total 12K
> drwxr-xr-x 3 root root 7.0K Jan 1 1970 .
> drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
> -rwxr-xr-x 1 root root 0 Jan 27 14:09 01234567890123456789
> drwxr-xr-x 2 root root 512 Jan 27 14:09 dir
> -rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
>
> I can only think that it is mounted incorrectly, that mkfs
> is bugged, or that I didn't understand the image being created.
>
> Any thoughts are appreciated,
>
> Dan
>
> On Mon, Jan 27, 2025 at 1:31 PM Michael Saunders
> <oka...@gmail.com> wrote:
>
> The FAT12 driver in the codebase does not support
> directories.
>
> --
> You received this message because you are subscribed to
> the Google Groups "MikeOS" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to mikeos+un...@googlegroups.com.
> To view this discussion, visit
> https://groups.google.com/d/msgid/mikeos/CACtjVkFpn3%2BbTYE%2BsWQ88ZummbhAfKV1X3AJCQgvSWwYcvmUwA%40mail.gmail.com <https://groups.google.com/d/msgid/mikeos/CACtjVkFpn3%2BbTYE%2BsWQ88ZummbhAfKV1X3AJCQgvSWwYcvmUwA%40mail.gmail.com>.
> total 12K
> drwxr-xr-x 3 root root 7.0K Jan 1 1970 .
> drwxr-x---+ 3 root root 4.0K Jan 27 14:09 ..
> -rwxr-xr-x 1 root root 0 Jan 27 14:09 01234567890123456789
> drwxr-xr-x 2 root root 512 Jan 27 14:09 dir
> -rwxr-xr-x 1 root root 0 Jan 27 14:09 test.txt
>
> I can only think that it is mounted incorrectly, that mkfs
> is bugged, or that I didn't understand the image being created.
>
> Any thoughts are appreciated,
>
> Dan
>
> On Mon, Jan 27, 2025 at 1:31 PM Michael Saunders
> <oka...@gmail.com> wrote:
>
> The FAT12 driver in the codebase does not support
> directories.
>
> --
> You received this message because you are subscribed to
> the Google Groups "MikeOS" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to mikeos+un...@googlegroups.com.
> To view this discussion, visit
>
> --
> You received this message because you are subscribed to the
> Google Groups "MikeOS" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to mikeos+un...@googlegroups.com.
>
> To view this discussion, visit
> https://groups.google.com/d/msgid/mikeos/c0ceb318-ed7c-41b2-a4fa-6ba5353c4586n%40googlegroups.com <https://groups.google.com/d/msgid/mikeos/c0ceb318-ed7c-41b2-a4fa-6ba5353c4586n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the
> Google Groups "MikeOS" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to mikeos+un...@googlegroups.com.
>
> To view this discussion, visit
>
> --
> You received this message because you are subscribed to the Google
> Groups "MikeOS" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mikeos+un...@googlegroups.com
> <mailto:mikeos+un...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "MikeOS" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mikeos+un...@googlegroups.com
> To view this discussion, visit
> https://groups.google.com/d/msgid/mikeos/938137d9-aebf-453b-9906-672fc9f7b431n%40googlegroups.com <https://groups.google.com/d/msgid/mikeos/938137d9-aebf-453b-9906-672fc9f7b431n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages