Antoine, after your first patch, getIncludedFiles would return the names like they appeared in the patterns. I.e. if you matched **/GAMMA.XML and the file was gamma.xml, you'd get the uppercase version. I think this may have been the original behavior as well.
When I played with it to get the case-insensitive matching going again, I realized that this is wrong for Unix. Most tasks will do a new File(basedir, includedFile[i]) somewhere and this is going to fail as GAMMA.XML isn't there on a case sensitive file system. I simply fixed a bug that's been present for a long time but left undetected and almost surely nobody would use case insensitive matches on a case sensitive filesystem. On Windows, on the other hand, this simply doesn't matter. The same is true (unfortunately) for a couple of other OSes with case insensitive filesystems like MacOS X using HFS+ or OpenVMS. It also probably doesn't matter for mounted SMB shares from Windows boxes or *FAT* partitions mounted into your Linux/*BSD/Solaris x86 box. Your getCanonicalPath fix will not catch the situation for any OS other than Windows (the way it is coded right now). It will also slow down scanning considerably, probably to the point that your prior optimization gets undone. And it would probably break in the presence of symbolic links if we applied it to OSes that support them. Given that, I'd rather remove the getCanonicalPath part and change the test cases to work with the older version like you did before. We'll have to include a couple of more conditions to it, but that's all. The behavior change shouldn't be visible for case-insensitive file systems, IMHO. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
