Combuster wrote:
Since empty directories are universally supported i dont think ignoring them would be wise.
I daresay I support the motion. Besides: how would you copy anything to an SFS disk? In every OS I know, in you copy a directory tree, with or without files, the OS/file manager/whatever first creates a directory and then copies thing in it... That would be impossible if empty directories are not supported! And even if it were possible (making the mkdir syscall a dummy function), the idea behind SFS is to make it
simple, not crippled.
Brendan wrote:
The "empty directory" support does complicate things though. For example, if the file "/foo/bar/hello.txt" is deleted then the SFS driver may need to search for "/foo/bar/*" to see if it was the last file in the directory, and search for "/foo/bar" to see if an entry for the directory already exists, and (if necessary) create an entry for the empty directory "/foo/bar".
For the original version of the specification, the SFS driver would behave as if directories didn't exist at all - the file "/foo/bar/hello.txt" was treated exactly the same as the file "-foo-bar-hello.txt", and no searching was necessary to make sure the directory structure remained consistant. {...} To be honest, I'm still wondering if support for empty directories is more hassle than it's worth, or if there's a better/simpler way to support empty directories.
(Luring siren chant)
Parent-directory-link... easy... simple...
Pype.Clicker wrote:
Brendan wrote:
The other thing I'm wondering is whether or not someone like Microsoft could take the specification, make their own patented modifications and call it "SFS version 1.1" (and if there's any way to prevent this).
You cannot patent something that is "obvious to someone being in the domain" or that is "prior art". By releasing it, you clearly make it prior art. There will be the archive.org website to show evidence of the initial release (though officially, a notarial proof would be better, though clearly too expensive).
While you cannot patent something in the public domain, you
can do a slight modification and release it under a propietary license (closed source) arguing that the whole code has changed and forbidding anyone else from implementing anything like the "new features" - which might cripple the implementor's possibilities of creating an open source driver. I think a BSD-like license, or even the LGPL, would be best. And of course, don't forget the "no warranty whatsoever, not even for merchantibility or fitness for a particular purpose" thingy
Combuster wrote:
About the spec itself:
One thing i kindof find missing in the specs is sfs's relation to partitioning (or maybe i'm confused or undereducated about that). Right now its obvious what sector 0 should be like when you have a full-sfs floppy or a hybrid sfs-fat floppy. Now what if i have a partitioned HD and i want sfs to occupy some 200 mb as second partition. Two things: would all pointers become partition-relative or absolute, and what would be a default partition type for sfs-only disks.
Well, I haven't even imagined such a problem... I don't know if any of you, people in this thread, think otherwise, but I've always thought that all block numbers, etc, were partition-relative. I mean: in floppies they span the whole disk because floppies have no partitions, but in a SFS hard disk partition, the "superblock" is the first block
of the partition, and so on. That is also the easiest way and safest: you just open, for instance, /dev/hda1 and let the disk driver translate your logical partition-relative block numbers into LBA disk-relative sector numbers. And you don't risk eating the MBR/GPT, you allow the partition to be relocated with something like Partition Magic were it needed, etc.
A partition should know only about itself: encapsulation is ignorance of the whereabouts of other partitions, and ignorance is bliss.
