Re: [fuse-devel] how to handle unknown file sizes

[Mikael B. <zjr...@co...>]

> i want to write a filesystem in fuse that does the following:
> map a source folder with flac-files to a new virtual filesystem, wich
> streams those flac files through an audio-codec like ogg and give the
> encoded data back when those virtual ogg files are read. filesystem sho=
uld
> be readonly.

  That's a great idea. I even think that in the end, a general purpose
file format translator filesystem could be built, but FLAC to ogg is
pretty cool right now.

  Note that you could modularize your filesystem by keeping the
FLAC->PCM and PCM->ogg parts as separate as possible. It would ease
extension of you concept (e.g. FLAC->mp3 could be easily built from
PCM->mp3).


> now i have some problems:
> [...]
> is there a way in fuse to have kind of named pipes?

  The FUSE file-read interface is random access oriented, so if you use
a stream oriented interface to your codec code, you need to write a
random-access-to-stream conversion layer. But although I don't think that
any random access PCM->ogg library exist, random access FLAC->PCM should
be supported by the FLAC library.

  As for the random-access to stream conversion layer, that could be
done in many ways:

1) read the entire stream from start to seek point on each read,
2) same as 1) but reuse the stream if the next read requests the
   very next data block,
3) cache the entire output stream,
4) cache only a certain amount of the tail of the stream,
5) cache the internal state of the codec at various points in the
   encoding process

  In each of these, "caching" could be done only for the time while
the file is open, but it could also be stored in a more persistant way,
for later reuse. It could also be made public for others to use, but
that is an entirely other problem.

  So 1) is likely to be too inefficient for any kind of use (the first
O(n=B2) codec :-) but 2) might very well work well enough for general
music listening. Just don't seek too much.

  3) would consume a lot of memory (or disk) if the cached data was kept
between opens, but it would provide very easy random access. 4) is of
limited use except in the case of small seeks around the current read
cursor.

  I think 5) is a nifty idea, but it would require the codec to
expose a backup-restore interface to its inner state, which is not very
likeky in practice.


> 1. in the readdir function, i dont know the filesize of the resulting
> encoded file. as workaround i used just a "big" filesize, which works f=
ine,
> but i dont think its the right thing todo. is there a better way to sol=
ve
> this?

  Just read the entire "file" once and store the resulting size
somewhere, along with file modification time. It will be slow, but
only the first time, and it doesn't need much storage space.


  I'm not sure all this helps, but I do wish you to get this nice hack
to work.


  Mikael