File names are NOT case sensitive on Windows
--------------------------------------------
Key: VFS-239
URL: https://issues.apache.org/jira/browse/VFS-239
Project: Commons VFS
Issue Type: Bug
Affects Versions: 1.1
Environment: win xp
Reporter: Stephan Schuster
Fix For: 1.1
Extracted from mailing list:
I just encountered the following problem with Commons VFS on Windows:
FileSystemManager fsManager = VFS.getManager();
FileObject fo1 = fsManager.resolveFile("c:\\test.txt"); // lower case
FileObject fo2 = fsManager.resolveFile("C:\\test.txt"); // upper case
System.out.println(fo1.equals(fo2)); // false but should be true
A while ago i was wondering why AbstractFileObject does not overwrite equals()
or hashCode() but uses a simple object comparison (see
http://www.mail-archive.com/[email protected]/msg01655.html).
Mario Ivankovits answered:
"The current VFS implementation (if you do not use anything else then the
only-working SoftRefFilesCache) ensures that two resolveFile will return the
same object if you ask for the same filename, thus, in terms of VFS there is
nothing bad with the object comparison."
That's right, however, the caching mechanism uses a TreeMap hashing file
systems by a so called FileSystemKey which encapsulates their root path as an
implementation of FileName (on Windows: WindowsFileName). Comparing two such
FileSystemKeys internally results in a simple String comparison where e.g. "c:"
and "C:" are considered different. In the test case listed above, VFS will
therefore create two instances of FileObject, one for "c:\\test.txt" and one
for "C:\\test.txt". An object comparison between both obviously returns false
even though it's the same file.
Since file names are not case sensitive on Windows, equals(), hashCode() and
compareTo() of WindowsFileName should probably convert all paths to lower case
before comparing them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
