[poppler] UniqueFileStream and deleted files

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

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