On Thu, Jun 17, 1999 at 05:27:47PM +0100, kevin lyda mentioned:
> quick summary: he's mad.
No, Looney. But I don't worry about things like that anymore, since I know
it's hereditary.
> "John P. Looney" burst across the net:
> >On Thu, Jun 17, 1999 at 04:24:43PM +0100, kevin lyda mentioned:
> > At first, I want a fsdb daemon would running from cron, doing something
> >like locate. Say, every day. Then, you can do simple SQL style queries on
> >the metadata, names, sizes, permissions (want to find all the setuid/gid
> >progs on the system - takes 3 seconds on a system with 15,000 files).
> but *why*?
Because locate and find are either to slow or too crap for the job at
hand.
> >% mkdir wavs ; cd wavs
> >% ln -s `dbquery --list name=\*.wav` .
> > And then, all your wav files would be in the current directory.
> i see this, and that's why locate exists.
Now think of things like:
dbquery --list attribs=rws* uid=0
> > Eventually, I want VFS hooks that update the SQL database every so often,
> >telling it when new files are created & stuff. I'm kinda scared about doing
> >stuff like this - I am stored atimes and mtimes - so this could slow things
> >down a lot (though there shouldn't be a problem buffering it - after all,
> >we don't mind if the fsdb is lost in a crash).
> then you'd have to rebuild it. and how to you tell a filesystem to
> cache - and where? is it a mount option, or something in /proc?
You wouldn't have to rebuild it. If it's a database, you just change the
fields in question.
The VFS hooks would be done as so:
have a "dbfilesystem", which is just a kernel module that looks like a
filesystem. What it does is accept (say) a read request, and stick a
"inode 2392 read at time 928381823812" or "inode 2832 deleted" message on a
queue, then call the ext2fs read method. After a while when the system is
quiet, it sends all these messages off to userspace, to get logged into a
database. That's very simple caching, seeing as it's not that critical that
the data get shipped out when the system is busy.
> > You know the way that Win95 has a "recent documents" list - imagine if you
> >had a directory of .txt files that were owned by you, and written to less
> >than a day ago !
> yeah, but it's not built into the os! this is a gnome or gtk level
> thing. i'd rather have the open file widget recording each open
> since it could also record what app did it, etc.
That's one more way of implementing it: the libVFS that comes with GNOME.
Problem being that apps have to be re-written to work with it. Anyother
idea is to place hooks for copy/move/read/write in libc, with ld_preload,
instead of going straight for the kernel's knickers. Though I'm not sure
how to catch file creation & stuff...
> i don't want to rain on any parades.
Rain away. It makes things clean.
> i still think writing an emacs
> distribution would be fun - or even worse a linux distribution done
> entirely with intercal (http://www.muppetlabs.com/~breadbox/intercal-man/)
> - now that would be a cryptic os! but i really don't think this
> would be received well on linux-kernel.
Stop that. You are being silly. Intercal was written for doing AI, not
operating systems ;) (as in, it turns your brain to jelly, and then you
seem to talk more like Eliza than a human).
> > Cool...now how the fuck to implement that logic...
> the find source?
Indeed. Down already ;)
Kate
--
Microsoft: One of the best reasons in the world to drink beer
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
