A question to programmers.
Do you know, how seek() works here? It definitely doesn't work like C fseek().
seek(N,0) works like fseek(N,1) from C.
Do you know any way to seek to an absolute position? I find reopening the file each time I need to seek() quite an ugly solution...

I do not belive there is support but I'm not 100% positive, honestly I did not try to figure out if it worked or not, I went for implementing a solution that I knew worked. The way we got around this in the dictionary application was to use 'grep' and 'sed'. Also we noticed a performance issue from using SONY's default API, sed/grep gave us the speed performance needed to search through large files in a reponsive time frame.

See the source for detailed examples

=X=

Well, all I managed to ind out about seek is that it can move forward and backward only. And the param is relative. I came up with the following workaround - maybe it's not very beautiful but it works and is a drop-in replacement for most uses of new Stream.File().
It changes seek behavior from fseek(n,1) to fseek(n,0), but it can be easily extended to allow mode choosing (Probably the best thing would be mode 0-relative 1-from the beginning 2-from the end, to make it backward compatible)
It also won't work for files, that are open for writting - it uses static fsize variable - if the size changes, the calculations won't be accurate any more - I'll need to chage all the write*() so that they update fsize...

function File4(name,mode) {
var z;
if (!mode) mode='r';
z = new Stream.File(name,mode);
z.fsize=z.bytesAvailable;
z.oldseek=z.seek;
z.seek=function(n) { this.oldseek(n-(this.fsize-this.bytesAvailable))}
return z;
}


As for the method - I've read the source and that is why I've decided to use tree based index - if I keep offsets there, I can avoid grepping through the file and can read only a small fraction of data. It also frees me from one-line-per-word limitation - if I store offset and length in the index tree, I can index whatever I want.
Greetz