[poppler] UniqueFileStream and deleted files

[Adam Reichold]

Hello,

Am 25.03.2013 08:44, schrieb Thomas Freitag:
> Am 25.03.2013 00:51, schrieb Albert Astals Cid:
>> El Diumenge, 24 de març de 2013, a les 16:31:05, Adam Reichold va
>> escriure:
>>> Hello,
>>>
>>> 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
>>>>>
>>>>> escriure:
>>>>>> 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
>>>>> space.
>>>> 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
>>>> effort?
>>> 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.
>> We still have the file open, it should work.
> Ok, ok, I surrender. If You just post it to find a mug who will do it,
> then open a bug report and assign it to me :-) Even if I don't feel like
> to open an issue again which I just closed after working on it round
> about 9 months, it is easier to make the mistakes by my own instead of
> searching errors from others :-)
> But I'm too busy in the moment with other projects to do it immediately,
> so it will take probably a while.
> 
> Cheers,
> Thomas

I would like to help implementing and testing this. Preferably under the
advisement of Thomas. If he feels like that would actually help, that is.

Regards, Adam.

>>
>> Cheers,
>>    Albert
>>
>>> Best regards, Adam.
>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>>> Cheers,
>>>>>
>>>>>     Albert
>>>>>> Cheers,
>>>>>> Thomas
>>>>>>
>>>>>>> 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. :)
>>>>>>>
>>>>>>> FYI.
>>>>>>> _______________________________________________
>>>>>>> poppler mailing list
>>>>>>> poppler at lists.freedesktop.org
>>>>>>> http://lists.freedesktop.org/mailman/listinfo/poppler
>>>>>>>
>>>>>>> .
>>>>>> _______________________________________________
>>>>>> poppler mailing list
>>>>>> poppler at lists.freedesktop.org
>>>>>> http://lists.freedesktop.org/mailman/listinfo/poppler
>>>>> _______________________________________________
>>>>> poppler mailing list
>>>>> poppler at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/poppler
>>>>>
>>>>> .
>>>> _______________________________________________
>>>> poppler mailing list
>>>> poppler at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/poppler
>>> _______________________________________________
>>> poppler mailing list
>>> poppler at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/poppler
>> _______________________________________________
>> poppler mailing list
>> poppler at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/poppler
>>
>> .
>>
> 
> 
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
>