On Jan 12, 2009, at 5:15 AM, Schuster, Stephan (Wilken GmbH) wrote:
Hi together,
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.
Any other ideas?
Please create an issue in Jira. If you would like to create a patch
please feel free. ;-)
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
