Vincent van Ravesteijn - TNW wrote: >>> Do we need a new class that we use internally. In this class we store > >>> a filename, which is case-sensitive on case-sensitive filesystem, > that >>> is guaranteed to be a long filename and not a short one (on Windows), > >>> that is not a symlink, that is relative or absolute (pick one or > both).
If you do it like that please be careful that the normalized name is only used for checking equivalence. In the past we invested a lot of work to ensure that file names stored in .lyx files stay always exactly like the user entered them (relative, absolute, case etc). This is IMHO important, think e.g. of documents that are both edited on machines with case sensitive and on others with case insensitive file systems. In other cases it is important that relative names stay relative and absolute ones stay absolute. BTW, I am pretty sure that you do only need to check the equivalence of two filenames in a few cases (e.g. when opening .lyx files). For example, if you have the same file in two graphics insets using different names, you do not really need to know that both files are the same. Of course that may result in two conversions, but given the difficulties with the equivalence check and caching it might even be faster accumulated over the whole editing session. Or if the user changes the included file, and e.g. only changes the case, the document should be marked modified. It would be very annoying if LyX was so "clever" to recognize that both names are equivalent and not let the user save the document. I believe that the performance problems could be solved quite easily by basing FileName::operator==() on simple string comparison again and implenting an equivalence() method that is used only when needed. >>This could work, though it looks as if we're duplicating what QFileInfo >>does, and we might run into similar problems about caching to what we >>had before. I don't know---but I think this makes some sense out of why >>they want to return false if the files don't exist. The problem, as I > see >>it, is that QFileInfo objects are getting created so often, which > requires >>filesystem access, even independently of the caching stuff. And I'm not >>sure how that can be avoided. > > Why is the class called FileName by the way ? Because the original purpose of this class was to store file names (and not more). Before this class was introduced, file names were stored as plain strings. Sometimes they were absolute, sometimes relative. To make it worse, the base directory of relative names was not always clear. Therefore that class was introduced, which encapsulated a file name and made sure that the base directory of relative names was always known (and it did some minor other stuff, too). During the transition to unicode it was extended to handle filename encoding conversions, too. > This really sounds like a > class that governs the FileNAME and all related things. And QFileInfo > really sounds like things that have to do with the physical file. Exactly. Unfortunately the current FileName class mixes these things. > Anyway, I want to have a class which can freely be instantiated and > another class with the warning that it can have performance issues > because it's related to files on the disk. We might duplicate things, > but with our own simple FileName class we are _sure_ that we don't > access the disk. By the way, to convert filenames and stuff we still can > use QFileInfo to be cross-platform. We just use it once, and when the > filename is in our own class, we are sure that it has the correct > format. > > That was the idea. What you describe is exactly the orginal idea of the FileName class and can be seen e.g. in the 1.5.x sources. Georg
