Re: file as a directory

[Amit Gud <amitgud1@gmail.com>]

On Wed, 24 Nov 2004 11:32:13 +0100, Helge Hafting <helge.hafting@hist.no> wrote:
> Amit Gud wrote:
> 
> 
> 
> >On Mon, 22 Nov 2004 16:04:28 +0100, Helge Hafting <helge.hafting@hist.no> wrote:
> >
> >
> >
> >>You won't get .tar or .tar.gz support in the VFS, for a few simple reasons:
> >>1. .tar and .tar.gz are complicated formats, and are therefore better
> >>   left to userland.
> >>
> >>
> >
> >Agreed that .tar.gz is a complicated format, but zlib is already in
> >the kernel. It _should_ simplify inflate and deflate of files. And as
> >compared to .gz format, .tar is much simpler, I guess.
> >
> >
> >
> >>   It is hard to make a guaranteed bug-free decompressor that
> >>   is efficient and works with a finite amount of memory.  The kernel
> >>   needs all that - userland doesn't.
> >>
> >>
> >
> >I think, finite amount of memory is the concern of worry, not the rest
> >... if we could rely on zlib.
> >
> >
> >
> >>2. Both .tar and .gz  file formats may improve with time.  Getting a new
> >>    version of tar og gunzip is easy enough - getting another compression
> >>    algorithm into the kernel won't be that easy.
> >>
> >>
> >
> >Doesn't zlib in the kernel gets updated as the formats change? If not,
> >.tar formats would be worth trying first as proof of concept.
> >
> This is not so easy, as you have to audit the new version for
> correctness.  It is not the end of the world if tar or gzip
> occationally crashes on some corner case.   The kernel
> must not do that though.
> 

Yes, thats what I said in my last post...if the archive looks improper
forget it.

> And then there is the much more complicated issues when
> writing into such an archive.  You skipped that part, or
> are you looking for a read-only solution only?
> 

I'm coming up with something soon, along with the proof of
concept....to wrap up all scenarios....need some time ;)

AG