QTemporaryFile Problems

ModelTech

I am trying to use QTemporaryFile as a means to temporarily store an image available from a QIODevice Device during the execution of my app. I have the following code that creates the QTemporaryFile as part of a constructor:

    QDataStream InStream(Device);
    ImageFile = new QTemporaryFile(TempDir->path() + QDir::separator() + "image.XXXXXX");
    ImageFile->open();
    QString TempName = ImageFile->fileName();
    if (!ImageFile->exists())
        qDebug() << "Error: Could not create Temporary Image File";
    QDataStream OutStream(ImageFile);
    const int BlockSize = 1024;
    char Block[BlockSize];
    int Length = 0;
    while ((Length = InStream.readRawData(Block, BlockSize)) > 0)
        OutStream.writeRawData(Block, Length);
    ImageFile->flush();
    ImageFile->close();

The destructor contains the following code:

    ImageFile->remove();
    delete ImageFile;

Between calling the constructor and destructor, a QPixmap is created from the QTemporaryFile.

This all works perfectly when I run it on Linux (actually WSL - Ubuntu 20.04) from within QtCreator. However, when I run it outside of QtCreator, the QTemporaryFile is not (always) created. What can be wrong here?

JonB

@ModelTech said in QTemporaryFile Problems:

However, when I run it outside of QtCreator, the QTemporaryFile is not (always) created.

So you are saying you could remove all your code to do with streams, images etc., all you need is the statement ImageFile = new QTemporaryFile(TempDir->path() + QDir::separator() + "image.XXXXXX"); (plus perhaps the open() and fileName()) and that will, at least sometimes, fail to create a file? And you test this via the !ImageFile->exists() in the code you show, as opposed to from another process or by looking in /tmp?

Could you clarify whether when it does not work (e.g. "outside of QtCreator") you still mean you are running under Linux (WSL), not Windows?

If so, I am unclear exactly what https://doc.qt.io/qt-6/qtemporaryfile.html#details

Note: On Linux, QTemporaryFile will attempt to create unnamed temporary files. If that succeeds, open() will return true but exists() will be false. If you call fileName() or any function that calls it, QTemporaryFile will give the file a name, so most applications will not see a difference.

is telling us. I see that you are calling ImageFile->fileName(), and also you use a template for the filename as opposed to the default of no template, but I still don't know how to read/interpret what they say as to whether exists() will find an actual file or not.

ModelTech

@JonB From what I understand from the documentation of QTemporaryFile is that creating the object with new does not actually create the file. You need to call open to do so. However, as your quoted note indicates, that will attempt to create an unnamed file (which is not necessarily successful). Following the same note, I therefore subsequently call fileName to ensure that it the QTemporaryFile has a name. The test of existance in my code should therefore now only fail in case the disk is full. At least, this is how I understand the documentation...

With "outside of QtCreator", I mean that I run the deployable variant within the same Linux (WSL) context. This deployable variant includes all the necessary dynamically linked libraries as a stand-alone package (i.e., without QtCreator).

JonB

@ModelTech
I do understand about open() and fileName(). But I find the docs phrase

so most applications will not see a difference

quite unclear to understand, don't know what they are saying here. In any case I acknowledge that you call open() & fileName() prior to exists().

I asked you to remove all the code to do with writing to the temporary file. Presumably all that matters is the code up to if (!ImageFile->exists()), assuming that is reporting false and that is all you are interested in?

Creator does not have or supply any libraries, DLLs etc. for your application to use, so I do not how running inside Creator vs outside affects the behaviour. I am not saying that does not matter, nor that you might not use different libraries depending on, say, your PATH inside vs outside of Creator, but Creator does not supply libraries for your application to use. One thing: I assume the "outside Creator" means Release not Debug build, are you doing same build inside Creator to compare?

Christian Ehrlicher

@ModelTech said in QTemporaryFile Problems:

I therefore subsequently call fileName to ensure that it the

Why do you need a filename for a temporary file at all? What's the gain?

JonB

@ModelTech
Under Ubuntu 22.04, Qt 5.15 supplied from distro, the following code

#include <QCoreApplication>
#include <QDebug>
#include <QDir>
#include <QTemporaryFile>

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    QTemporaryFile *ImageFile = new QTemporaryFile(QDir::tempPath() + QDir::separator() + "image.XXXXXX");
    ImageFile->open();
    QString TempName = ImageFile->fileName();
    if (!ImageFile->exists())
        qDebug() << "Error: Could not create Temporary Image File";

    return a.exec();
}

seems to always work and create a named file in /tmp each time. Tested compiled for Release & Debug both inside & outside of Creator. Maybe you should try just this? Can you find a pattern as to when the exists() returns false?

If you are not wanting the file to be accessed from another application you do not need the temporary file to have a name, as per @Christian-Ehrlicher's comment, which you should answer as to why you do need it.

If you do need it, and for whatever reason (e.g. maybe WSL for all I know) you cannot get it to work reliably/consistently to your requirements, you can of course just "roll your own" temporary file without having to use QTemporaryFile.

ModelTech

@JonB I also expected that there should be no difference whatsoever between running it from within the context of QtCreator or not, but that is however exactly what is happening and it does not matter if it is Release or Debug... It's very weird and I never had this before...

The problem exposes itself from the fact that I need to create a (scaled) QPixmap based on the QTemporaryFile. This gives the error: QPixmap::scaled: Pixmap is a null pixmap

@Christian-Ehrlicher I also need the QTemporaryFile to be concrete with a filename etc to be able to parse & process it with libtiff elsewhere in my app.

JonB

@ModelTech
I asked you to try my minimal code sample, did you do that?
If you say the problem happens "sometimes", can you find a pattern? (Per chance, if you put in a delay after open()/fileName() and before exists() is that relevant?)

ModelTech

@JonB The minimal code works perfectly fine (It took me some time to be able to isolate this part)... I will now try your idea of a delay.

Christian Ehrlicher

@ModelTech said in QTemporaryFile Problems:

process it with libtiff elsewhere in my app

What do you do with libtiff which can Qt not do directly? And TiffOpenExt() allows to pass a custom read function if you really need special tiff functions.

ModelTech

@ModelTech Unfortunately, the idea of a delay does not seem to work...

JonB

@ModelTech
If my standalone, minimal example always works but your "larger" code does not, maybe there is something there. Let's start by changing the fileName() line to:

QString TempName = ImageFile->fileName();
qDebug() << "Filename created" << TempName;
if (!ImageFile->exists()) ...

What do you get for the qDebug() line when the exists() fails? (And can you please state categorically that your "failure" case means that exists() returns false and it writes Error: Could not create Temporary Image File, as opposed to any other way of "detecting the file does not exist", you still have not made that clear?)

ModelTech

@Christian-Ehrlicher I actually started like that, but I need to process the TIFF images in a way that Qt unfortunately does not support. Qt translates everything to RGB-based color spaces and that is the primary thing that must definately not happen in this case... libtiff is the primary library that supports everything I do need, except for displaying the images. That is what Qt is very good at :)

Christian Ehrlicher

Then pass a custom read function to open or simply use a regular file (or fix the bug in your code whereever it is)

ModelTech

@JonB Good remark! When I mentioned 'exists', I meant that I was looking at the /tmp directory. I have not seen the code produce any qDebug messages in any case...

Let me do some more testing with the full code by introducing a lot more qDebug() messages to see where the problem arises (and eventually gets exposed by the QPixmap error). It is a bit of a poormans approach to debug, but this is the only way given that it all works fine when debugging with QtCreator ;)

JonB

@ModelTech said in QTemporaryFile Problems:

I meant that I was looking at the /tmp directory. I have not seen the code produce any qDebug messages in any case...

That is a totally different case! I assumed since you showed the debug message if exists() fails that was what you were seeing. You should have said!

Then the first thing to check is: the file will be deleted any time ImageFile is deleted. Since QTemporaryFile derives from Qobject start by attaching destroyed signal:

connect(ImageFile, &QObject::destroyed, this /* some object which persists beyond your ImageFile's lifetime */, []() { qDebug() << "ImageFile destroyed!"; } );

Do you get this debug output any time prior to when you expect it to be destroyed (in your destructor)?

Christian Ehrlicher

@ModelTech said in QTemporaryFile Problems:

QDataStream InStream(Device)

What is Device here? A socket?

ModelTech

@JonB Sorry for beying unclear earlier. No, I do not get any 'destroyed' messages at all, even not when the destructor is called! It is however really no longer existing after the destructor is called ;)

Nevertheless, based on your ideas I did get a lot further now :) I have been able to check that the QTemporaryFile does still exist at the moment that I create the Pixmap. So, the problem exposed by the QPixmap message does not seem to originate from the existance of the QTemporaryFile at all. Although this hasn't solved my problem, I was looking completely in the wrong area...

JonB

@ModelTech said in QTemporaryFile Problems:

No, I do not get any 'destroyed' messages at all, even not when the destructor is called!

Well, you ought to! Changing my example to have

QObject::connect(ImageFile, &QObject::destroyed, qApp, []() { qDebug() << "ImageFile destroyed!"; } );
...
delete ImageFile;

does give me the message!

But if you are moving to look at a different area you may not care.

ModelTech

I found the problem! I needed to add the relavant Qt image format plugins to my deployable package...

Thanks for all the help in directing me to an approach that enabled me to identify the actual problem :) :) :)