Re: FSSetForkSize writing massive amounts of data over network?
Re: FSSetForkSize writing massive amounts of data over network?
- Subject: Re: FSSetForkSize writing massive amounts of data over network?
- From: James Bucanek <email@hidden>
- Date: Wed, 2 Feb 2011 22:40:19 -0700
Jim Luther <mailto:email@hidden> wrote (Wednesday,
February 2, 2011 5:22 PM -0800):
I was writing a similar answer. The only minor correction I'll add is:
FSSetForkSize() sees that you are making the file larger and so the File
Manager is writing a single byte of 0 at the new EOF - 1. If a file system
doesn't support sparse files and doesn't do an optimization (as Mark explained
below) like HFS Plus (and that kind of optimization wouldn't be possible on a
network file system), then the file system will have to write zeros to fill
the space between the old EOF and the new EOF to have correct POSIX behavior.
Clearly, this is something new, now that OS X is running on top
of BSD. In the olde days, and according to the documentation,
FSSetForkSize makes no guarantees about what appears between the
old EOF and the new EOF.
Mark's recommendation, "We've generally advised applications to use
FSAllocateFork (or the equivalent at other API layers) to try to reserve the
space up front, and then just write to the file when they need to, and handle
errors appropriately.", is my recommendation, too.
Good advice, in principle. But FSAllocateFork has been broken,
and apparently continues to be broken, so it's not a practical
alternative. Although if it worked reliably, it's clearly the
best choice.
--
James Bucanek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden