[Interest] using QTemporaryFile for post-mortem debug logfiles?

Konrad Rosenbaum konrad at silmor.de
Mon May 22 15:08:34 CEST 2017


Hi,

On Mon, May 22, 2017 13:39, René J.V. Bertin wrote:
> On Monday May 22 2017 13:21:05 Konrad Rosenbaum wrote:
>
>> From my experience I'd recommend you go the long route and actually
>> implement the date/time comparison(*). For one: problems have the bad
>> habit of forcing you to restart the application multiple times, so
>> you'll
>> lose at least the first instance of the problem.
>
> I hear you and thought of that too. There may be a middle ground which is
> good enough here:
> create the files with a date (and possibly PID) stamp, but rename them to
> a predetermined fixed name after they're closed cleanly just before
> program exit.

> That leaves around the logs of sessions that crashed, but the less
> interesting logs can be subject to a cheap rotation scheme without a lot
> of risk.

This only works if the problem is a crash. Only a minor percentage of
problems are crashes. Especially if the application uses network
connections.

> I'm curious though, why does my QTemporaryFile trick to auto-remove only
> empty files not work as expected?

Because the QTemporaryFile is not about a file being empty, its about a
file being temporary. It creates a normal file under a unique name and
normally deletes it when it is closed. This happens so you can safely use
the file to store data that you need during your current session only. You
can turn the deletion step off so you are able to handle the file with
other functions after you closed it. In either case QTemporaryFile does
not care a rat's furry backside about the content or lack of content of
the file... ;-)



    Konrad

PS: the time that it took us to discuss the pros and cons of a proper log
rotation scheme is not so much smaller than the time you need to implement
it ;-)




More information about the Interest mailing list