[Top][All Lists]

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

Re: Gunzip and bunzip2 stores

From: Ludovic Courtès
Subject: Re: Gunzip and bunzip2 stores
Date: Thu, 12 Sep 2002 16:44:36 +0200

On Thu, Sep 12, 2002 at 04:33:50PM +0200, Marcus Brinkmann wrote:
> > Anyway, I started thinking about it. One issue is that I don't know exactly
> > what to do with the store runs in store_set_size (): I guess that for the 
> > file
> > and zip stores it should be quite simple since they should have only one run
> > which we would just enlarge/reduce accordingly. However, the solution may 
> > not
> > be that simple for other stores with more complex run lists. Perhaps we 
> > should
> > just let each store modify its run list inside its set_size method?
> Well, it is one question if such a function belongs to libstore and another
> one how to implement it in each case.  Luckily, we can answer the second
> question partially and let all uncovered cases return EOPNOTSUPP.  BTW,
> maybe the function should be called store_truncate for analogy?

Ok, so the store runs handling should rather be in each class and
store_set_size () would just call the set_size () method and nothing more.

Regarding the function name, the reason for choosing store_set_size () is
because it is close to file_set_size, the analogous function in the Hurd fs
interface. OTOH, it would be called only for truncating files (enlarging files
can be done by calling store_write) and also POSIX have truncate and

> Anyway, if you need this feature for some useful program, and adding this
> feature avoids the need for reimplementing libstore, then I think it is well
> worth to add it.  In particular as it seems to make some moderate amount of
> sense for resizable stores like files.

Yes, it would be useful at least for files and zips and does not require too
many changes to libstore.


reply via email to

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