bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: httpfs, tarfs --help


From: Adam Olsen
Subject: Re: httpfs, tarfs --help
Date: Fri, 21 Dec 2001 18:08:25 +0000
User-agent: Mutt/1.3.23i

On Fri, Dec 21, 2001 at 05:02:52PM +0100, Jeroen Dekkers wrote:
> On Fri, Dec 21, 2001 at 03:34:02PM +0000, Adam Olsen wrote:
> > On Fri, Dec 21, 2001 at 03:16:34PM +0100, Jeroen Dekkers wrote:
> > > On Fri, Dec 21, 2001 at 01:39:39PM +0100, Marcus Brinkmann wrote:
> > > > However, if you don't pass an argument to tarfs, it can assume that the 
> > > > tar
> > > > file is what we call the underlying file of the translator.
> > > > 
> > > > If you have a file /tmp/foo, you can put a translator on /tmp/foo while
> > > > keeping the original file intact.  All normal file accesses go to the
> > > > translator though, the file is "hidden", it lies under the translator
> > > > (underlying file).  But the translator always gets a port to its 
> > > > underlying
> > > > file, so it can access it.  This case is what I wanted to illustrate.
> > > 
> > > Is it possible to make that transparant? I.e. you can just cd into a
> > > tarfile without using settrans first, because somethings detects the
> > > tar.gz extensions and knows to run the tarfs translator on that.
> > > 
> > > I've been thinking about two ways to do that:
> > > 1) Set the translator field of every tarfile to /hurd/tarfs.
> > > 2) Use some special `extensions translator' which automatically sets
> > > translators for files with known extensions.
> > 3) as 2, but triggered when you you have a "foo.tar.gz" file and try
> > to open "foo".  Probably useful when other programs recognise the .gz
> > extension and try to open it as a zip file.  (well, I suppose the
> > dir/file distinction would protect foo.tar.gz files, but plain foo.gz
> > files would still be vulnerable)
> 
> I think letting the translator do it is the Right Way. Implementing gzip
> in every application is useless anyhow IMHO. So I think we should fix
> the apps. :)

There's two ways for an app to support gzipped files:
a) within the app itself, by recognising files with a .gz extension
b) using a translator

You can't use the translator *all* the time, because you may want to
manipulate the gzipped file itself.  And doing it in the app has to be
duplicated for every app.  Therefore there IS no "right way".  Do
whatever is most convenient.

> 
> > More important than if you *can* make it transparent, is if you *want*
> > to make it transparent.  But I think it's definetely worth
> > implimenting.
> 
> I think there are a lot of people who will use it. Just think about it:
> download a tarball, cd into it, build the program and install it. With
> or without the option of storing the changes in the tarball itself (You
> could make some kind of shadowfs thing). People who dislike it can
> always turn it off, so that's no problem. We should also be sure to make
> it secure.

I agree.  Btw, naming a non-gzipped file .gz breaks opening them with
vim, and presumably every other app that already supports gzipped
files.  Being compatable is very important.


-- 
Adam Olsen, aka Rhamphoryncus



reply via email to

[Prev in Thread] Current Thread [Next in Thread]