Vincent van Ravesteijn wrote:
That said, QFileInfo already caches this data. So why wasn't that
good enough? Why did Bennett have the problem that required the
refresh() calls that lead to the additional filesystem access? I
think the answer is that the first time the comparison was made, the
file didn't exist, and THAT fact got cached, so that the next time
the comparison was made, it returned false, even though the filenames
were the same. (This is the odd behavior of QFileInfo that Vincent
ran into somewhere else.) So we had to refresh. I think this case is
dealt with properly here. If we get nothing back from
canonicalFilename(), then we just compare the paths.
Yes, something like this happens indeed. Note further that the caching
of QFileInfo only makes sense if you access the same object. In e.g.
filetools.cpp:makeAbsPath() we make a new filename object every time,
which thus has a new QFileInfo object, which automatically doesn't
know about any cached values. This means that if we keep the user
defined path in e.g. InsetInclude, we create the absolute path every
time when we want to compare this value with the one in theBufferList().
OK, so this isn't good enough. I guess what we'd need, if we wanted to
continue this approach, is a more global cache, mapping absolute
pathnames to canonical pathnames.
I'm still bothered, though, by the fact that QFileInfo already does
this. Of course, the refresh() calls were undoing the effect of that.
But maybe, as said in the other message, they can just be removed
without loss now. Of course, if I remember right, you had to turn off
BOTH the internal_path() and refresh() calls to deal with the problem,
so by itself this observation doesn't help.
rh
