W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: Using FileWriter.truncate() to extend the length of a file?

From: Eric Uhrhane <ericu@google.com>
Date: Thu, 16 Sep 2010 15:05:47 -0700
Message-ID: <AANLkTi=nODdV5QaCHGTW4NX-cYf5y1-r6DjE+x0RXXPg@mail.gmail.com>
To: Darin Fisher <darin@chromium.org>
Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Fri, Aug 27, 2010 at 3:58 PM, Eric Uhrhane <ericu@google.com> wrote:
> On Thu, Aug 26, 2010 at 2:04 PM, Darin Fisher <darin@chromium.org> wrote:
>> I noticed that FileWriter.truncate() can only be used to shorten a file, and
>> there does not seem to be a good way to grow a file using FileWriter without
>> appending data to it.  By contrast, the POSIX ftruncate function can be used
>> to grow a file (zero padding it):
>> From ftruncate(2):
>>   "If the file previously was larger than this size, the extra data is lost.
>>  If  the  file  previously
>>    was shorter, it is extended, and the extended part reads as null bytes
>> ('\0')."
> I see no reason we can't add this; I just left it off for simplicity,
> but your use case makes sense.
>> I think there are use cases for wanting to grow a file in advance of writing
>> data to it.  For example, you might implement a system that downloads chunks
>> of a file in parallel using multiple XMLHttpRequest objects.  The chunks may
>> arrive out-of-order.
>> A possible alternative API would be to support seeking beyond the end of the
>> file or writing to a starting offset that is beyond the length fo the file.
>>  It may also be reasonable to support all of those in addition to truncating
>> to an offset greater than the length of the file.
> I think this may be a little messier, and there's no reason to make up
> a new paradigm when the POSIX one is well-known and sufficient.
> If nobody objects, I'll just add it.

Received on Thursday, 16 September 2010 22:06:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC