Open Bug 979233 Opened 10 years ago Updated 2 years ago

Truncate mechanism in file handler

Categories

(Core :: Storage: IndexedDB, defect, P5)

defect

Tracking

()

People

(Reporter: guypaskar, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424

Steps to reproduce:

I have created a FileHandler to write a file into, I get the file in chunks not necessarily in their order. i.e if the file is 1,000,000 bytes and a chunk is 3000 bytes, I can even get the last chunk as the first chunk. 
There is no way to append the chunks not in their order. 


Actual results:

I can't append the chunk I get if it is not "in-order".
What I do - I create an arraybuffer of zeros with size of (wanted_chunk_index - current_file_length) and append it and only after I append the needed chunk.
This cost a lot of memory and sometimes crashes the browser (if the needed index is too large)


Expected results:

Modify truncate to be as the following:
if truncate(position) and position is smaller than current file size - the operation removes all the bytes starting at the index corresponding to the parameter

if truncate(position) and position is larger than current file size - the operation adds zeros from the current file length to position.
Would be happy to hear if someone has an idea to workaround this
Well, we disallowed this feature (extending files by calling truncate) on purpose IIRC. But maybe we should reevaluate it ?
Flags: needinfo?(jonas)
Component: Untriaged → DOM
Product: Firefox → Core
In the filesystem API we renamed 'truncate' to 'setSize' so that it would be clear that it could increase the filesize.

However the filehandle API that we currently support is a Gecko-only feature. And given that no other browser vendors have expressed interest in implementing it, it's unlikely to move further. So I'm not sure that it's worth spending much time on.

That said, if the change here is trivial then I'd be ok with landing it. But do keep in mind that this feature might go away at some point in the future.
Flags: needinfo?(jonas)
You mean that fileHandle API will go away? I thought that your implementation of the filesystem API is using the filehandle API. I don't see why we should "remove" the feature - It's a good API and can remain even if other vendors will not implement.

In any case, to my use-case it is a needed feature and I would be happy to see it landing to gecko and firefox.

Thanks,
Guy
Mozilla's goal is to create a standardized web that runs across all browsers. We don't like proprietary solutions even if they happen to be exposed through web technologies.

The filehandle API was an experiment to see if we could solve various use cases using IndexedDB. However unless this experiment ends up adopted across browsers it's something that we should remove.

We certainly might reuse parts of the current FileHandle implementation when implementing the filesystem API. But the two APIs are different and so code won't automatically carry over.
Sure. I totally agree. Just saying that for now with the lack of filesystem API in gecko Filehandle gives a very good solution for working with files and indexedDB - That said, when filesystem API will be ready it will be awesome!
What Jonas said, but I'll try to fix this bug, so they can use current FileHandle API until filesystem API in gecko is available. Actually, they were looking for a filesystem API, but since there's nothing like that in gecko at the moment, I suggested to use FileHandle API in IDB.
Assignee: nobody → Jan.Varga
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Version: 27 Branch → unspecified
Jan - Any progress here?

Thanks
Component: DOM → DOM: IndexedDB
guy paskar, do you still use the file handle API ?
Assignee: jvarga → nobody
Flags: needinfo?(guypaskar)
Assignee: nobody → jvarga
Priority: -- → P5
Assignee: jvarga → nobody
Flags: needinfo?(guypaskar)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.