[Interest] Strange undeletable QTemporaryFile. Is it a bug?

[Thiago Macieira]

On terça-feira, 27 de agosto de 2013 16:55:44, Alex Malyushytskyy wrote:
> QIODevice::close() - closes the device
> 
> when
> 
> QTemporaryFile::close() truncates and repositions, but doesn't *close* the
> file. If you really want to close, destroy the object or force it to open a
> new
> file (with a new name).

QTemporaryFile::close() calls QIODevice::close(), so it does what any 
QIODevice is expected to do.

> According to above, example below does not make sense
> cause you can't delete file after call to bar(). .
> Relying on  interface is already broken.
> 
> >     void bar (QIODevice& zzz)
> >     {
> >     
> >         // ...
> >         zzz.close(); // Oops
> >     }

You couldn't delete in bar() anyway because you don't know if this is a file or 
not. It could be a QProcess.

Now, assuming you have a QFile above instead of QIODevice, you still can't be 
assured that you can delete, because:

a) the directory could not be writable by you
b) the file could be locked by another process
c) the file is in a read-only filesystem, including virtual filesystems (e.g., 
  the resources filesystem)

The way I see it, you have a problem in your design. So I will agree with you 
when you say "example below does not make sense". It doesn't. It's not a good 
design.

Since QTemporaryFile auto-deletes, you shouldn't call a function that tries to 
delete it. You should only call that function if you know you opened a QFile 
and that it should be deleted.

> The whole problem is that QTemporaryFile::close() does not do what it is
> supposed to do.

I disagree. It does exactly what it's supposed to do.

You meant to say: "QTemporaryFile::close() does not do what I expected it to 
do"

Note: QTemporaryFile::close() is QFile::close(). The difference is in the file 
engine.

> And I see only 2 ways to fix it:
> 
> 1. Change the interface so user can't call function which is source of the
> problem.
> 2. Change implementation so close works as expected.

Since I disagree that it is a problem to begin with, I disagree that there 
needs to be a "fix". So for me, we have option 3: do nothing.

> >> The only way to make it work would be for close() to unset the fileName()
> 
> again. When open() is called again, it creates a new file name based on the
> template.

That would be fine.

Except that people expect fileName() to return something non-empty after 
close().

> >> Which is exactly what you don't want.
> 
> I might be missing something , but I would can't see why not.
> 
> If you say that lifetime of the temporary file (including name) is limited
> by opening and closing
> I do not see any security issues.
> It is also what I would expect temporary file to do by default.

To be honest, it's what I would have preferred.

However, people expect to have access to the file name after close(). 
Therefore, we can't release (delete) the file at close() time.

Anyway, this behaviour is now too ingrained in Qt. It's unlikely to ever 
change.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130827/e95976b5/attachment.sig>