The previous == and != checks had just been against the file NAMES,
which meant you could get file1 != file2, >if the names were symlinks
pointing to the same file, and names with different capatalizations
would be seen >as different on Windows, VFAT, etc. So Abdel changed it
to call QFileInfo::operator==, which dealt with both >problems. But that
led to Bennett's problem: The comparison sometimes rested on old data;
hence the need for >the refresh.
The old way of checking the file NAMES would also have been based on
'old' data or not ?
No. Because it just checked the names, whereas the new one used
QFileInfo::operator==. And QFileInfo would cache the data, so it could
be out of date. See below....
That's what I don't understand, was it like this:
A file should be copied when the target fileNAME was different from the
source fileNAME? When changing to the ==() operator, we checked whether
the two files are both existent and have exactly the same name
and _size_ (that is used in QFileInfo::operator==()).
Not quite, because QFileInfo::operator== is supposed to return true if
they're the SAME FILE, independent of whether they have the SAME NAME.
The size check seems like something they do to avoid checking the more
complicated stuff, viz., canonicalFilePath(). I guess it must be
cheaper. But what they're checking for is whether it's the same file.
Thus if one of the two
objects has a cached value that the file did not exist and the other (a
new FileName object) says the file does exist. ==() returns false for
the two files. Then copying a file onto itself will fail.
But this shows an example in which it is of _no_ interest whether the
files are exactly the same. It is only of interest to know whether the
path is the same, so QFileInfo::==() should not be used.
Does this make sense ?
Maybe it's already clear, but the point now is that it isn't enough to
check if the *strings* giving the paths are the same. That's what we
used to do, and it was behind the bugs Abdel was trying to fix. E.g.,
suppose you have a buffer open with file.lyx. Now you ask LyX to open
FILE.lyx. Previously, LyX would have done this, since it didn't realize
the files are the same. And now you're editing the same file twice, and
LyX is happily overwriting your changes. Worse, imagine you have
newfile1.lyx, and now you create a new file which you ask LyX to save as
NewFile1.lyx. You can get similar problems if file.lyx is a symlink
pointing at otherfile.lyx. The solution to this, again, was to use
QFileInfo, which uses canonicalFilePath() to avoid these kinds of problems.
The problem Bennett saw was due to failure of one of the checks (in
trunk) in Converter.cpp, line 364 or 500, if I remember right, due to
caching. I'd have to look more closely to be sure, but I think those
checks had better be for file equality, not just string equality, lest
you overwrite something you don't mean to be overwriting.
Richard
