KDE 3.5.7 and Beagle: file being deleted immediately after opening in kpdf

[Frederik Himpe]

On Mon, 27 Aug 2007 13:27:21 +0200, Josef Spillner wrote:

> On Saturday 25 August 2007 17:33:23 Frederik Himpe wrote:
>> A Beagle developer analysed the problem a bit more in the above ticket
>> and we have some more details. When Beagle indexes the downloaded pdf
>> file, it writes some extended attributes to the file. Because KPDF
>> watches the file with KDirWatch, this triggers kpdf's slotFileDirty()
>> in kdegraphics/kpdf/ part.cpp and makes it reload the file.
> 
> I do not agree with the analysis in the bug report that "it is ok to
> write metadata to the file". If a file is downloaded, it should be left
> alone. Why can't beagle write its data elsewhere? How would it index a
> read-only CD-ROM full of PDF files?

Beagle is not meant to index CD-ROM's, it does not handle multiple 
removable media AFAIK. But if you would let it scan your read-only cd 
mount point, it would store all the indexes in an sqlite db (which it does 
too if extended attributes are not available on the indexed file system).

> The reload error is a second (distinct!) bug. My guess is that KPDF
> should not destroy the view when the reload fails. Konq/KHTML has a
> similar bug where if you load a page and click cancel you end up with a
> white window.

Well, one thing is clear to me: there is a mechanism in Konqueror which is 
supposed to remove a downloaded file once the application which opened it, 
does not need it anymore. It's this mechanism which is triggered, and 
which causes the problem. Maybe it simply reacts too sensibly to certain 
actions.

Could somebody familiar with this code take a look at this? Or tell me 
where is this piece of code in Konqueror which handles file deletion after 
a file has been downloaded and opened?

Thanks!
-- 
Frederik Himpe