[poppler] UniqueFileStream and deleted files

Albert Astals Cid aacid at kde.org
Mon Mar 25 12:05:38 PDT 2013 

El Dilluns, 25 de març de 2013, a les 16:41:35, Adam Reichold va escriure:
> 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.

All yours :-)

https://bugs.freedesktop.org/show_bug.cgi?id=62735

Cheers,
  Albert

> 
> 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
> 
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler

More information about the poppler mailing list