SimpleFS - Missing from WIKI and Brendan's site

[Kemp]

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

[Combuster]

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

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).
In short: fundamentally flawed.

[Habbit]

I hope you enjoyed your holiday - this thread has been dying a bit without you...

hmm... really? I don't know if I should take that as a good or bad thing... ???

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'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?
I suggest either adding a new "unusable index area block" index area entry type, with start/end blocks relative to the top of the disk (i.e., "block 0" would then be that with the volume identifier entry), or make all offsets volume-relative (which has the downside of files possibly having starts/ends in the reserved area/index area).

As for geometry, there is a thing called LBA....

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.


Oh, and one other thing. This happened yesterday:

The 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.

;D;D;D

Seriously! Why on Earth (or Dune, Terminus, Coruscant or wherever) would you use PRE.NET VISUAL BASIC?? Its... plainly masochistic!! Worse even than Win32 C++! The latter is painfully complex, forcing you to control everything, but VB is not only excruciatingly verbose, but also just as complex with its trailerful of keywords and its recurrent, braindamaged by-design decision of taking all control away from you...

But of course, you're free to choose your torture ::)

[Combuster]

If i had your IM address you'd have to block me if you didnt feel like a 10 hour speech about why i do NOT use vb.net.
So i'll keep it short: VB.NET is no longer basic, its C++ with basic keywords. And i dev twice as fast in basic than in any other language.
And since i intend to port a thing or two to FreeBASIC for my own OS i cant have the windows dotnet crap saying its "BASIC" when its not. 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...
But this is REALLY off-topic so i'll stop now.

From the current draft:

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.

Its there, you just have to know where to look.
so,
1) yes
2) 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).

As for that, you can just have the bad area markers extend into the index area - you can easily calculate the exact offset where you are unable to write index data (which is btw what i thought it was meant to do). The real problem is that you can not fragment the index area so parts of the index will be corrupted somewhere, which makes reasoning about it rather difficult

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.
But thats a thing you have to figure for yourself.

[Habbit]

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...

Lord VolBemort, I think... ;D
I have made a some serious apps in VB: one old db management program in VB6, and two more in VB.net, of which one is hashsum, published at sourceforge (though I no longer work in the VB version) and the other is an internet clock (little form that shows the @ time and it converts to and from normal dates).

The only thing I ever liked in VB is the "My" features - the very reason C++ programmers in the 90s kept boasting "VB programmes have all too easy" - especially My.Settings and My.Computer, but starting at VS2005, that is also easily accesible in C#, which is my language of choice because is java+VB with a bit of C++ if needed (unsafe blocks with pointers).

I find it quite respectable if you like the language, but you'll have to admit that VB 1) was used by every idiot in the 90s that, after achieving a form with a "hello" label and a "close" button, told everyone they were programming masters, and 2) is the second most obfuscated and error-prone language in the world unless you enable "option strict" and "option explicit" (which, of course, none of the idiots featured in 1 did). I say the second because, of course, the first is C with its #defines and its implicit automagical conversion of pointer types to void* and viceversa (thankfully that was removed in C++)

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

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).

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 bad

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.

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:

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()

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.
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)

[Candy]

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

Thanks, I'll add you (I grew up with basic, way pre-VB even)

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.

That's bull, your method works perfectly. You'll need an equivalent of llseek for the length of larger (>4GB) disks, but it works.

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.

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)

Yours already was reliable, but you didn't know enough to realise it.

[Habbit]

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.

That's bull, your method works perfectly. You'll need an equivalent of llseek for the length of larger (>4GB) disks, but it works.

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?

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.

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)

Yours already was reliable, but you didn't know enough to realise it.

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?


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?

[Candy]

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?

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.

[blip]

While looking for specifics on FAT+ I found LEAN FS and figured y'all might want to know about it. I haven't gone through it in any depth but here are some things mentioned in the article:

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.

[Combuster]

I've read the specs, and its designed to be a simple *nix-targeted filesystem. The spec hints that it contains ideas from Ext2, as well as some FAT things.

Pros:
- It stores timestamps, uids gids acls and some more that SFS omits, but which *nix systems live around.
- Its designed to be faster
- It supports fragmentation
- It supports softlinks/hardlinks natively
Cons:
- Its more complex than FAT, and far more complex than SFSs current spec
- They want to add things that will probably make it more complex
- It needs more data per file on average
- It is limited at 32 bit (16TB at max cluster size)

About the speed, it will definately beat SFS in normal desktop usage, although SFS is more efficient in adding and reading big files (basically what Pype described as usb-stick usage).

So, in SFS's principles i dont think its strong opposition. Since it doesnt support anything really new i think people will want to stick with ext2 for being its bigger brother.

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)

Btw, i wonder what the status of sfs is right now...

[Habbit]

Btw, i wonder what the status of sfs is right now...

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.

[B.E]

Just a couple of things I have noticed when reading the spec.

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.

2. Say you have a directory stucture
like

Code: Select all

/
+- Dir1/
  +- Dir2/
    +- file 1
    +- file 2
  +- file 1
  +- file 2
  +- file 3
  +- file 4
  +- file 5

Now say you want to add the file /Dir1/Dir2/file 3, What happens.

3. I sugest reordering the fields of both the Super-block, and adding a field that links filenames or have a fixed directory size(i.e 32 entries). I also sugest having each continuation entry have a link to the next entry(or 0xFFFFFFFFFFFFFFFF at the end).

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).

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.

[Habbit]

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.

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.

2. Say you have a directory stucture
like

Code: Select all

/
+- Dir1/
  +- Dir2/
    +- file 1
    +- file 2
  +- file 1
  +- file 2
  +- file 3
  +- file 4
  +- file 5

Now say you want to add the file /Dir1/Dir2/file 3, What happens.

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 SFS

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).

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:

• Boot partitions/floppies: their data does not change very often, and the simple structure of the filesystem makes it easy to parse from the 512-byte assembly boot sector
• Small media / USB-stick-type media: volumes with either a reduced size (floppies) or less than 10k files (usb sticks) can have their index area cached in memory, so the quite slow operations on it can be performed with considerable ease.

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.

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.

[Brendan]

Hi,

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)

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?

Considering that the file system is intended for transferring files between machines (and that you wouldn't use it if there's networking between the machines), the UID and GID is completely useless.

If the UID and GID don't make any sense, then most of the rwxrwxrwx flags are also useless. In addition, the eXecute flags are pointless - something that is executable on Windows probably won't be executable on a ARM processor running Linux or a digital camera.

That leaves 2 flags - everyone can read/no-one can read, and everyone can write/no-one can write. If a file can't be read by anyone, then it doesn't make any sense storing it in the file system to begin with.

So, now we've got one flag left that determines if the file can be modified or not. Regardless of how this flag is set the user can always copy all files somewhere else, format the disk, modify the files and copy them back. As a security measure it's worthless (much like the FAT file attributes that any user can change with the "attrib" command). The only thing it'd be good for is to prevent accidental modifications to the file.

So, is protecting files from accidental changes worth worrying about? IMHO probably not, considering that if files are being transferred from machine A to machine B then the original file will probably still be on machine A anyway.

BTW if you actually need security, store the entire file system on an encrypted partition (for e.g. use something like TrueCrypt). That way you'd need the right key to access anything, and people can't read your data by opening "/dev/fd0" in a hex editor or doing something like "dd --skip=131072 count=123456 if=/dev/fd0 of=foo/bar".


Cheers,

Brendan

[earlz]

hi I'm thinking about implementing sfs in my OS and also makign a tool or 2 for it
this is the most updated spec. isn't it? http://bcos.hopto.org/sfs.html#FS_Overview
and now then onto my questions
1. on fdd's what do you do about superblock and reserved area?
2. will sfs floppies be bootable?


ok and now for ideas for it..
3. why not store directories as special files, except for their contents(in data area, not index) is an index of all the files?
4. why do you store deleted file entries and directory entries?
5. with no file fragmentation with that basically mean if there is only 1 sector free where the file is and the only other sectors free are at the end of the media --would that mean you'd have to defragment everything to get space for that file?
6.how do you tell what sectors are free?