OSDev.org

Kind of wondering whether this is going anywhere soon...


I've started a new drawing of the database(ish) design and I've converted into C structs verbatim, without any speedups or anything. I know of a few places that I want sped up and I'm going to consider that in my next train journey, and when I've got those worked out I'll write up a big text (using a bunch from the posts here) to create a nice standard specification. It'll include "use cases", things you probably want to do, and how to do them properly.

Expect me to take up to three weeks for this, mainly because school eats up the next 2.5 weeks

Candy wrote:
Extrapolate the previous few things and come to the conclusion that it must be "yes".

1920, music had an artist, title, instruments and location.
1950, music had an artist, title, record company, instruments and location.
1980, music had an artist, title, record company, instruments, distrubution method (tape, record) and location
2000, music had an artist, title, record company, manager, instruments, distribution method (tape, record, mp3, cd, dvd-audio, ra), bit rate, location, genre.
2030, music had an artist, title, record company, manager, instruments, distribution method (tape, record, mp3, cd, dvd-audio, ogg, wma, aac, ra), bit rate, location, genre and what else?

Something to add to the list; album.
I think this should be included too, because if I want to search for songs only on that album, it would be IMO handy that i'd give the album name to a search program (local!) than i have to search for the album list, and then I would search for the song itself.

PS. If this wasn't the idea, it should be now

Hmm ... I've been talking about all that with muad-dib (local friend here) and it appears that, if
[*] i have a sufficiently-standardized way to manage the metadata-stream,
[*] there is an attribute telling the "file class" which would be an identifier giving a hint on how the metadata stream should be interpreted
[*] there is a mechanism to insert *listeners* on directories and open files (e.g. the "media library" program or whatever other "documents collection manager" can tell the system it is interested in receiving notifications about events such as "file renamed" or "file opened for writing", etc)

Then i should be able to do everything i wish concerning collections management, versionning, copy-on-write directories etc.

Whether the "listener" should be a FS plugin or an independent user-level program is unknown so far ...

Hi,

Pype.Clicker wrote: Whether the "listener" should be a FS plugin or an independent user-level program is unknown so far ...

The listener should be anyone at all (including user-level programs). A GUI would use this to determine if a "file exploerer" window needs updating, a text editor would use it to determine if the file it's working on has changed ("This file was modified - reload, save changes or cancel?" - I get this from the "Kwrite" editor often enough). How about some software that hides in the background and sets a "notify" on "/var/spool/mail/<username>" (or equivelent) and pops up a "You have mail" message?

There's a long list of uses...


Cheers,

Brendan

Pype.Clicker wrote: Hmm ... I've been talking about all that with muad-dib (local friend here) and it appears that, if
[*] i have a sufficiently-standardized way to manage the metadata-stream,

Suppose a second stream?

[*] there is an attribute telling the "file class" which would be an identifier giving a hint on how the metadata stream should be interpreted

The "file class id" attribute, plus the file type tables?

[*] there is a mechanism to insert *listeners* on directories and open files (e.g. the "media library" program or whatever other "documents collection manager" can tell the system it is interested in receiving notifications about events such as "file renamed" or "file opened for writing", etc)

That's an OS feature, which I was planning on btw

Then i should be able to do everything i wish concerning collections management, versionning, copy-on-write directories etc.

Whether the "listener" should be a FS plugin or an independent user-level program is unknown so far ...

Would still not be portable. Ask him what else you need for it to be portable.

As the M$ got the patent of FAT, what is the difference when we are considering the design of FS and its relative?

OK,
Regarding of FAT, it seems the discussion has start at 'Universal File System' thread, and, IMO. it is worth pulling it out and inserting into the FAQ to caution newbies.

I was just wondering.... why do we need this filesystem as opposed to filesystems that already exist? What exactly does it offer? I've been eyeballing the ZFS filesystem lately, and it seems to cover every feature/goal that has been mentioned in this thread and delivers even more. It's also been open sourced fairly recently. Two differences I've noticed so far is that it has no option not to timestamp and it depends on snapshots (with CoW!) rather than true diffed versions. What is an advantage of the filesystem we are discussing here over ZFS?

#
# Provable data integrity
ZFS protects all data with 64-bit checksums that detect and correct silent data corruption.

This alone make ZFS much to complex compared to the filesystem we were discussing here. The goal of our filesystem was to make it as simple as possible.