[poppler] UniqueFileStream and deleted files

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

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