On Tuesday, July 30, 2002, at 02:51 PM, Pelle Johansson wrote: torsdagen den 25 juli 2002 kl 03.15 skrev Wade Tregaskis: Is this still an efficient way of operating, in an increasingly linear [e. g. single-user] OS? I'm just thinking, if you could return from writes faster, the calling process can keep doing other things. My thought is that you could do this without breaking existing apps by performing any error checking [i.e. quickly verifying there is free space, among other things] immediately, returning fail if appropriate, or otherwise returning no error. You could then worry about physically getting the data to disk, seeing as this is the most time intensive part... Side note: I was taught that if you know how large a file you want to write you should use ftruncate() to set the file size before writing. That way the OS can optimize the location of the file on the hard drive. I've noticed Unix application are quite bad at doing this, so perhaps it doesn't apply in some OSes. Most Unices won't take advantage of this 'optimization', because the typical Unix file system allows 'holes' in the allocation. Thus, if you create an empty file, and truncate (or seek to a far corner of the universe), and write a byte, the intervening space will *not* be allocated. This is dependent on the type of file system, of course. The HFS+ file system does not support 'holes'. Regards, Justin PS: Reading "man ftruncate" leads me to guess that if you 'ftruncate' an empty, or short, file to a large size, nothing will happen on the disk (the man page says "at most 'length' bytes"). -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | If you're not confused, | You're not paying attention *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.