The Place to Start for Operating System Developers
http://f.osdev.org/
That's how windows thinks. Now, how do we know we are dealing with a softlink and not the result of ls > file. (WITHOUT labeling it .lnk).Kemp wrote: Softlinks can be supported without any modification at all simply by storing the link as an actual file with the path of the pointed-to file being the contents. No extra tables needed, no fancy twiddling
hmm... really? I don't know if I should take that as a good or bad thing... ???Combuster wrote: I hope you enjoyed your holiday - this thread has been dying a bit without you...
I'm a bit dense today. You said things like "start block" are relative to the start of the data area (I can't find neither that nor the opposite in the spec, just "start block in the data area"). So then, 1) a file starting in the first block of the data area would have a "start block" of 0, no matter if that happens to be sector #500 because there are 499 reserved ones plus the superblock; and 2) how does one mark an index area sector as unusable, if start block et al are data-area-relative?Combuster wrote: About offsets, volumes and such:
The spec afaik states something in the likes of "relative to the start of the data area", which means block 0 is indeed sector 1 on a regular floppy. (or partition offset + 1 on harddisks)
There is and will always be one reserved block: the MBR / superblock. (to ease the calculation: start block = volume start + reserved sectors, or 1 = 0 + 1 for floppies)
I know this is very bad style, but... do you happen to have a snippet? I had a look at mkdosfs code and... well... I couldn't understand a lot, just that it checks for floppies with a switch.Combuster wrote: As for geometry, there is a thing called LBA....
;D;D;DThe class is silent, only the occasional sound of a keypress or a mouseclick disturbing the humming noise of the computers. Some four or five people sit idly at the machines, doing grueling and obscene things such as reinstalling Windows, trying to figure out why a faulty NIC driver has brought the supposedly rock-solid XP kernel to its knees. Normality ensues, though the future inventor of the Infinite Improbability Drive is in the room.
But suddenly, a sickening scream tears the air. Many jump off their seats and look at the source of the yell, a teenager that is now convulsing on the floor, mumbling incoherencies and pointing at the screen. After five tense seconds in which noone dared to move, some finally get to help the young man. He looks pale and scared to death, and, to the question of "what happened", he answers "look" and points to the screen again. So the others look.
They look and they see some files open in GEdit, of which a "sfs.bas" is currently foreground. They smile at the paralysed teenager on the ground with an half-understanding, half-amused look, and one of them says "Don't worry, it ain't so bad... VB is now .net". "For begginers, though" adds another. But the fallen one remains frozen in place, so the third partner says "It's not like it was... VB 6". As he speaks the Forbidden Name, a shiver goes up their spines, and the one on the ground, known as Habbit, whispers "It is".
Five agonic screams tear the air.
Code: Select all
The number of reserved blocks (at offset 0x01B8) specifies the number of blocks that are reserved for the reserved area and the super-block. This value is also used to determine where the data area begins.
Lord VolBemort, I think... ;DCombuster wrote: Btw, its sortof racism to say VB's evil when you have no clue what its actually capable of, and unfortunately a LOT of people make that mistake. Didnt know though that saying VB6 is worse than saying "Lord Voldemort" though...
You can position the "bad index area block" markers topmost, near the volume identifier, so that they are read first (if that block is bad, the disk is screwed). Furthermore, it is possible to detect if the data just read is good or not (CRCs), so you just jump over it if it's badCombuster wrote: Agreed, there is a problem with bad area markers referencing to the data area and not to the index area. But then, you can jump into the index area anywhere without following any pointers, so how do you have the driver know it cant go there without traversing the index area (and consequently stumbing upon corrupt data, that might say bad things).
Oh my god, I'm being REALLY dense... When I say GEOMETRY I _don't mean CHS_. I mean how can I know the size of a volume. Currently I do something like this:Combuster wrote: as for LBA: It simply means that a disk can be addressed as sectors 0 - a lot (effectively getting rid of CHS translation). You just ask /dev/hdx for 512 bytes starting at address 512*sector. I think its default linux behaviour to think in LBA mode, but i'm not a linux guru, and i have no clue as to how to write filesystems for it, or FUSE for that matter. But i expect you can just ask the floppy driver to return sector xxx and it'll translate it to heads cylinders and sectors internally.
Code: Select all
fstream reader(volumeToFormat);
if (reader.fail())
throw invalid_argument("Couldn't open the volume");
reader.seekp(0, ios::end); // Goto end of stream (end of volume)
volumeSize = reader.tellp(); // Get current position
reader.close()
Thanks, I'll add youHabbit wrote: Edit: I added my MSN Messenger to my profile, so you can tell me about VB as long as you want. I'll be really happy to listen
(I grew up with basic, way pre-VB even)That's bull, your method works perfectly. You'll need an equivalent of llseek for the length of larger (>4GB) disks, but it works.That has worked OK many times and returned 1474560 bytes for 1440K floppies (2880 sectors x 512 bytes), but once I found one that returned more than 1600000 bytes (more than 3000 sectors), while its BPB clearly stated 2880. More amazingly, the anomaly went away when I formatted it with mkdosfs or mke2fs, I don't remember which. After that, my method returned once more 1474560.
Yours already was reliable, but you didn't know enough to realise it.And my question is: is there any reliable way of finding the real size of floppies or will I have to force anything near 1-2 MiB to my known floppy sizes? (as msdosfs does, or so I think)
I'm not using C streams, but the C++ ostream.tellp() method, which returns a "pos_type", and there the information ends (it's a type defined by a template of a template of a template...). I've, however, tried a sizeof(s.tellp()) in my AMD64, both in cygwin32 and ubuntu64: pos_type is 16 bytes long (128 bits!!). Could anyone confirm that size or tell me how to instruct autoconf to check for it?Candy wrote:That's bull, your method works perfectly. You'll need an equivalent of llseek for the length of larger (>4GB) disks, but it works.Habbit wrote: That has worked OK many times and returned 1474560 bytes for 1440K floppies (2880 sectors x 512 bytes), but once I found one that returned more than 1600000 bytes (more than 3000 sectors), while its BPB clearly stated 2880. More amazingly, the anomaly went away when I formatted it with mkdosfs or mke2fs, I don't remember which. After that, my method returned once more 1474560.
It is not from the moment the 1600 K (DMF?) disk becomes a 1440 K disk (even to my "reliable" method) after being formatted with mkdosfs or mke2fs. Furthermore, if I ever have to force lengths near floppy sizes to those known sizes, how will I tell between a floppy/image and a 1 MiB RAM drive?Candy wrote: Disks with over 1600000 bytes exist, they're called DMF disks and are formatted (low-level) with a higher sector count per cylinder. DOS and Windows don't care about the actual disk size for content though, they'll just use the BPB information instead.Yours already was reliable, but you didn't know enough to realise it.Habbit wrote: And my question is: is there any reliable way of finding the real size of floppies or will I have to force anything near 1-2 MiB to my known floppy sizes? (as msdosfs does, or so I think)
SimpleFS is public domain, it's the only license (by definition) that is trivial to understand. It's a license that gives you everything. You can even claim copyright on it (except that you'd have a bit of prior art that's public domain, so not many people would care). You can use it in anything without license trouble.Habbit wrote: And a strange but necessary question: I'm about to publish mksimplefs and the little part I've done of simplefsmount in SourceForge. Since SimpleFS is (for the moment) public domain, can I license my implementation as GPL or LGPL?
Overview
The mission of the LEAN file system is to provide a new free, simple, portable, personal file system alternative to the proprietary (and in part patented) Microsoft FAT file system, primarly intended for media exchange and for use with embedded devices, and to expand the file system functionality of the FreeDOS-32 free modular operating system.
...
LEAN aims to be even simpler yet to perform better at the same time.
Well, the linux fuse driver is still alive... or it should be - I'm currently in an exam frenzy at school. If I can work out how, I'll post the current source in the SF.net CVS, so you guys can see it, and (I hope) help me understand FUSE madness.Combuster wrote: Btw, i wonder what the status of sfs is right now...
Code: Select all
/
+- Dir1/
+- Dir2/
+- file 1
+- file 2
+- file 1
+- file 2
+- file 3
+- file 4
+- file 5
Well, my implementation would move the file entry to the first appropiate position in the index-area, expanding it down if needed. Space used up like this is not wasted, because, should the disk run out of free space, the index area can be compacted.B.E wrote: 1. Say you have a filenameA that is of a mere 94 (requires a full continuation entry). now say you add say 30 files disk. Now if filenameA is then renamed to name that has a size of 95(requires an extra continuation entry now). what happens. Does the FS driver move the directory to a new location or does the FS driver move everything after this entry down one slot.
What happens is that a file entry for "/Dir1/Dir2/file 3" is inserted at the first unused entry in the index area. Files in a directory do not have to be contiguous, neither in the index area nor in the data area. If you read through the spec and this thread, you'll see that the very concept of directories is... at the edge of SFSB.E wrote: 2. Say you have a directory stucture
likeNow say you want to add the file /Dir1/Dir2/file 3, What happens.Code: Select all
/ +- Dir1/ +- Dir2/ +- file 1 +- file 2 +- file 1 +- file 2 +- file 3 +- file 4 +- file 5
The original purpose of SFS was to be a (simple) patent-free filesystem for everyone to use as ey pleased. It is, however, very useful for two purposes:B.E wrote: BTW, if SimpleFS does not provide any support for block fragmentation, what is the purpose of the FS. Moreover if the FS is intended for simple OSes then if they want to "use" extend there OS they have to impelemnt a more simpler filesytem (i.e FAT, ext).
And why would you implement just ext3? Implement a full-fledged reiser4 driver, another one for NTFS (with perfect write support), all that in 512 bytes (minus the BPB) and just to boot your kernel. SFS is nowhere near ext3 in performance nor security, but it also is orders of magnitude simpler (which, for boot partitions or floppy-like media, is a Good Thing). The only thing I miss is some error resiliance, but simplicity means sacrificing some things.B.E wrote: Sure this FS could be implemented in no more then a couple of hours, but why would you implement it when you could implement ext3, in a little more time.
If you create a file on your Linux machine at home, how on earth can the UID and GID make sense to the WIndows machine at work?Combuster wrote:What SFS could learn from it, is that we might want to add uid/gid/rwxrwxrwx to the entries, and maybe native links (there are 'hacky workarounds' for these - Check Kemps post and my post a few metres up)