Re: Hurd Projects

[mike burrell]

Jeroen Dekkers (jeroen@dekkers.cx) said:
> On Sat, Dec 22, 2001 at 01:47:57PM -0700, mike burrell wrote:
> > there are certainly other uses for cachefs (though maybe it would need a
> > different name).  one thing i thought of was an FS sort of like Microsoft
> > Windows' Recycle Bin (except much cleaner).  instead of 'rm'ing a file, you
> > 'mv' it into a trash directory -- if the trash FS is full, then in it
> > (silently) deletes the oldest file on there.  i actually have something kind
> > of like this on my GNU/Linux machine, where i have a crontab entry that
> > deletes the trash daily, but a TrashFS would be much cleaner.  of course,
> > anything that caches could make great use of it.
> 
> I think having support for this is in the normal filesystem is better.
> There already exist undelete ext2 implementation and with the normal
> ext2 filesystem recovering files isn't that hard either, try the recover
> program.

well, first of all, i don't think there are any normal filesystems that have
"support" for undelete.  the capability for undeletion is mostly due to
coincidence.

really, though, i didn't implement my pseudo-expirefs because i have nothing
better to do.  i did it because i really needed it.  very often i had
deleted a file and then (sometimes just a few seconds later thought) "oops! 
i deleted the wrong file!" or something to that effect.  so, then i must
login to the server (because, of course, you can't undelete over NFS), and
then su root and "recover", which takes about 15 to 30 minutes.  then, i run
"file *" on the directory where i've dumped the possible suspects in order
to narrow it down, and then i go through the remaining undeleted files
manually until i find the one i want.  and then i curse, because it was a
large file and i only managed to properly undelete 64k of it.  things would
become much more difficult if i didn't have root access, as well :).  i
should point out that on many of my partitions, i can't undelete *AT ALL*
(i.e. on my ReiserFS partitions).

but, with my "trash" mechanism (which is really just a bash function), now
when i do something stupid, i just do "cp ~/.trash/deleted_file .", and i
get it back within a few seconds (or less).  much nicer.  the only problem
with it is that i use a crontab entry to clean it up, which i find
inelegant.

but, this expirefs would make the solution much cleaner, and has
implications to lots of different applications.  there are many times where
you would like data stored locally, but if it's not there, you don't mind
terribly.  cacheing and "trashing" are just two examples.

> > but, i think if we were to get this thing working well and quickly, the
> > proper order of operation would be:
> > (1) get squid working under the Hurd (has this even been done yet?)
> > (2) turn it into a translator
> > (3) slowly work at getting it to export a human-usable datacache
> > (4) once that's working, take out squid's conventional non-human-usable
> > datacache
> > (5) work at trying to separate network code from cacheing code and
> > eventually break it into two translators
> 
> I don't know the squid code, but I know that it's a very big proxy
> server used by many large ISPs. I'm not sure the code is usable to
> modify it in a translator. For the HTTP part, there exist libraries for
> that IIRC. You might have more luck trying that.

not usable?!  everything's usable with a bit of work :)

your suggestion for an HTTP library is a good one, though.  it all depends
on how stable and featureful they are.  as squid is used at many large
ISP's, as you say, i know very certainly that it is stable and useful :). 
plus, it does many other things apart from HTTP (FTP and SSL, for example).

-- 
 /"\                                                 m i k e   b u r r e l l
 \ /     ASCII RIBBON CAMPAIGN                                mikpos@shaw.ca
  X        AGAINST HTML MAIL,
 / \      AND NEWS TOO, dammit