[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KTempFile wierdness
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-05-30 21:28:07
[Download RAW message or body]

On Thursday 31 May 2001 00:48, shaheed wrote:
> Drat and double drat. I found a problem with the OLEFilter handling of 
> embedded objects. The problem is as follows:
> 
> 1. koFilterManager creates a KTempFile to receive the output from a "file" 
> filter. It uses defaults for the name "KTempFile tempFile;" near line 434.
> 
> 2. The OLEFilter decides the top level MS Word contains an embedded file, and 
> invokes koFilterManager to handle it (near line 156).
> 
> 3. This is a recursive call back to step 1, and results in a temporary file 
> of the same name as step 1 being created.
> 
> 4. The OLEFilter embeds the returned data from step 3 into the file from step 
> 1 and tidies up by deleting the file from step 3, and also therefore the file 
> for step 1.
> 
> Result: /me totally confused for several hours!
>
> Now, this used to work many months ago, so perhaps the behaviour of KTempFile 
> been changed? The new code uses the fakes.c vesion of mkstemps: but somehow 
> the check for exclusivity seems to be broken.
> 
> Any clues? It would be really good to fix this before the next version of 
> kdelibs, so that koffice can use it!

The analysis of what happens is correct, but not the blame assignment.
The reason why the two calls to KoFilterManager end up with the same tempfile name
isn't due to a bug in KTempFile, but due to this :

            KTempFile tempFile; // create with default file prefix, extension and mode
            if (tempFile.status() != 0)
                return QString::null;
            d->tempfname=tempFile.name();

See the last line ? This stores the name into KoFilterManager !!!
Basically, it's not re-entrant as it is, and you use it in a re-entrant way....

    QString tempfname; // yes, ugly :) 

Apparently someone knew it was a hack :)

Ah, the reason why this changed recently is that the MSWord filter got converted to
a "bulletproof" one. i.e. it runs out of process. And that's the case where it uses
this string (see KoFilterManager::receivedStdout).

I think the real fix is to create a map, KProcess <-> some struct,
so that KoFilterManager::receivedStdout knows which process this is about,
and uses the correct data (document, tempfname etc.)

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]