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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
