[poppler] UniqueFileStream and deleted files
adamreichold at myopera.com
Sun Mar 24 08:31:05 PDT 2013
Am 24.03.2013 06:32, schrieb Thomas Freitag:
> Am 23.03.2013 20:08, schrieb Albert Astals Cid:
>> El Dissabte, 23 de març de 2013, a les 20:01:58, Thomas Freitag va
>>> Am 23.03.2013 18:59, schrieb Ihar `Philips` Filipau:
>>>> On 3/23/13, Ihar `Philips` Filipau <thephilips at gmail.com> wrote:
>>>>>> (i tried to find a way to duplicate a FILE* but failed)
>>>>> How did you duplicate FILE*?
>>>>> How did the `fdopen( fileno(oldfile), mode )` failed?
>>>> Nope. This is the right way:
>>>> int new_fd = dup( fileno(oldfile) );
>>>> FILE *new_file = fdopen( new_fd, mode );
>>> Duplicating the FILE pointer in that way is not a solution: I tried it
>>> that way when I began to implement thread safe feature: At least under
>>> Ubuntu and gcc the duplicated file pointer uses the same underlying
>>> buffer, and that corrupts the thread safe feature.
>> Exactly, it is the documented behaviour
>> "They refer to the same open file description and thus share file offset"
>>> That's why I used the
>>> fileName to create a complete new file pointer.
>>> Of course we can do it in that way if we detect that the file is deleted
>>> (and only then!), but a program which use threads to render different
>>> pages the same time will then render garbage :-(
>> No. We either write the file back to a temporary location as i
>> suggested in my
>> initial mail, or use the only fd with locking. I think i'm favoring
>> the second
>> use case since writing the file back might not even work if we run out
>> of free
> I think, You're second solution is quite easy to implement (I mean
> really only easy to implement, it will take some time to change every
> code snippet and deeply test the changed code): since FileStream already
> use it's own buffer, there is no really need of the underlying system
> file buffer. So implementing something like a sharable GooFile (or
> extend gfile) which can be locked and remember the next read position in
> FileStream and then do something like gfile->read(readposition, buf,
> buflength) wouldn't really reduce the speed. But then I would prefer use
> the low level file handles instead of the file pointer. And it's even
> better than to write platform specific code and rely on Windows that the
> open file is not deletable and search for a Mac solution.
> Then the UniqueFileStream mechanism and the streamOwner instance
> variable can be removed, too.
> On the other hand: who deletes a just opened file and expects stability
> of the application which just opens the file? Is it really worth the
Seems I am a bit to the party, but for what it's worth: I asked myself
the same question as Thomas. Providing a file object that takes care of
looking and per-thread offset seems like the best solution (ideally
implementing using low-level I/O), but is it really that useful to be
able to continue rendering unlinked files as long as Poppler fails
gracefully, i.e. does not crash.
Best regards, Adam.
>>>> It is OK to use *NIX function here - the dup() - since deleting open
>>>> file can happen only on the *NIX-like OS, Mac OS X included. Windows
>>>> doesn't allow that. Correct me if I'm wrong. Tested on Linux, HP-UX
>>>> and Solaris for the safety sake: the fclose() would close the dup()ed
>>>> file descriptor.
>>>> Though I'm not sure how to integrate that with the rest of the portable
>>>> code. :)
>>>> poppler mailing list
>>>> poppler at lists.freedesktop.org
>>> poppler mailing list
>>> poppler at lists.freedesktop.org
>> poppler mailing list
>> poppler at lists.freedesktop.org
> poppler mailing list
> poppler at lists.freedesktop.org
More information about the poppler