• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Request For Comments On File Insert API
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Request For Comments On File Insert API


  • Subject: Re: Request For Comments On File Insert API
  • From: James Bucanek <email@hidden>
  • Date: Fri, 21 Mar 2008 09:04:53 -0700

Quinn <mailto:email@hidden> wrote (Thursday, March 20, 2008 3:40 AM -0000):
1. Would this API benefit your application or any application you know?

One problem this would solve for me is that I would like to occasionally expand the format of my data file's headers. This often results in the headers getting bigger, which poses the problem that the rest of the file need to "move down" to make room.


An finsert_np() call would make this much simpler and more efficient.

From a practical standpoint, it might not help me that much as the ability to expand the file headers with new information would still need to support older operating systems that didn't include an finsert_np() function. So I'd still have to write the code needed to reorganize the file without it.

3. We could also implement an fdelete_np API, to delete chunks of an
aligned size at an aligned offset.  Would this benefit your
application or any application you know?

Yes, yes, yes!!! While the finsert_np() intriguing, an fdelete_np would be extremely welcome. My application (QRecall) creates massive (100s of GB) database files that, over time, accumulate large amounts of unused space. One method for reclaiming this space is an incremental compact procedure that packs the active data records together until all of the unused space is at the end of the file, at which point the file can be truncated. This is horrifically time consuming and data transfer intensive.


The ability to incrementally release chunks of data in the middle file back to the operating system would make this vastly more efficient and truly incremental.

(Footnote: I assume this would be supported on a per-volume basis. Would Apple consider AFP support so that the call would work on network mounted volumes as well?)

Do the above three
restrictions pose serious limitation on your use of such an API?

My biggest problem is that my primary data file is currently being accessed via the Carbon APIs. Rewriting it to use the BSD APIs wouldn't be my favorite way to spend a weekend, but it would be worth it.


--
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


References: 
 >Request For Comments On File Insert API (From: Quinn <email@hidden>)

  • Prev by Date: RE: Request For Comments On File Insert API
  • Next by Date: Re: Request For Comments On File Insert API
  • Previous by thread: RE: Request For Comments On File Insert API
  • Next by thread: Re: Request For Comments On File Insert API
  • Index(es):
    • Date
    • Thread