Re: [Bibdesk-develop] FVSplitSet?

[Maxwell, A. R <ada...@pn...>]

On 03/18/09 12:16, "Christiaan Hofman" <cmh...@gm...> wrote:

> On Wed, Mar 18, 2009 at 7:56 PM, Christiaan Hofman <cmh...@gm...> wrote:
>> 
>> You're right that it can be deleted and modified. However, it /is/ listed as
>> open. 

...which is not a problem in itself.

>> Moreover, I wonder if the data provider doesn't run into trouble when
>> you do any of this? Is it really a good idea to map a file for a long time
>> when you're not really opening the file?

The main problem for the data provider is that the file length could be
changed between the stat and mmap calls, and not using copy-on-write access.
I fixed that.  The kernel is managing the file after the mmap, so it's
keeping it open but it's not counting as an open file descriptor.

> Correction, the trash refuses to permanently delete the file when it's linked
> in BD. 

That very important piece of information was entirely absent from the bug
report.  I tried renaming it and moving it in Finder, editing it with vi,
and deleting it in Terminal...all of which worked.  I see this regularly
with Finder, with various applications; to copy a new file over an old one,
you have to trash the old file, then move the new one in place.  It's an
incompatibility with the Unix way of handling files.

> This goes away with CFDataProviderCreateWithData.

This can blow up your memory footprint, so you'll have to retune any caching
heuristics appropriately.

> Anyway, I doubt it's right to keep a hold on the file. So still my question
> whether _FVSplitSet is relevant without it? And should any pdfDoc be released?

FVSplitSet is as far as I recall only relevant to the mmap data provider,
but I can't be sure.