no, it is more handwaving. The dirty marking you describe will be done for a partial page at the old end of the file. Any additional pages will normally be left unallocated, and the operating system will provide zeros at read time when you try to read them. This makes them appear zero-filled, without actually zero filling anything.
Having said that, I would expect certain operating systems (like DOS) to actually do the zero-filling and complete it before returning from the call. --David Garfield On Tue, Jan 24, 2012 at 14:00, Simon Slavin <slav...@bigfraud.org> wrote: > > On 24 Jan 2012, at 6:51pm, David Garfield wrote: > >> From the ftruncate page: "If the file size is increased, the extended >> area shall appear as if it were zero-filled". >> It doesn't have to write zeros, just act like it did. > > That's a bit of handwaving. What happens is that the file system doesn't > itself write zeros to the disk surface. It puts zeros into the cache of the > sector in memory and marks that sector as dirty (i.e. needing to eventually > be written back to disk). So if the program doesn't write to that sector and > just releases it, those zeros do eventually get written to disk. But if the > program does write to that sector the disk surface only gets touched once, > not twice, which is faster. > > So it doesn't write zeros to disk, but it does write zeros to the bit of > memory that represents that bit of disk, and arrange that (unless the program > overwrites them) they'll be written to disk eventually. > > Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
