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

[Constantin Makshin]

I agree that explicit object deinitialization (closing files, freeing
memory, etc.) in the callee is a bad thing (implicit through destructors
or object's management of its [internal] data is OK IMHO).
bar() was just a hypothetical example with the idea "rely on the
[expected] behavior of the declared type, not specifics of the actual one".

On 08/28/2013 05:51 AM, Thiago Macieira wrote:
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130828/518c2127/attachment.sig>