[jboss-jira] [JBoss JIRA] (JBVFS-166) Deployment archives that are symlinks do not get cached properly when jboss.vfs.forceCanonical is set to 'true'

> If forceCanonical is true, subsequent accesses of /vfs/symlink/im_a_symlink_too.jar resolve to /othertmp/the_real_jar.jar, which isn't found in either the permanent or real cache.

Deployment archives that are symlinks do not get cached properly when jboss.vfs.forceCanonical is set to 'true' --------------------------------------------------------------------------------------------------------------- Key: JBVFS-166 URL: https://issues.jboss.org/browse/JBVFS-166 Project: JBoss VFS Issue Type: Bug Security Level: Public(Everyone can see) Affects Versions: 2.2.0.GA Reporter: Mike Clark Assignee: Ales Justin When a deployment, such as an .ear file, is a symlink and the jboss.vfs.forceCanonical property is set to "true" to address JBVFS-137, the deployment fails to be properly cached leading to an ever increasing vfs-nested.tmp directory. JBVFS-137 addresses the problem that permanentRoots in the VFSCache get set according to their canonical path by the URL PropertyEditor. Without the fix, if the deployment directory is a symlink, it will be stored in the cache using a different path than lookups will use. To correct this, when checking for items in the cache, the canonical path must be used, or else there will not be a match. Setting the jboss.vfs.forceCanonical property enables conversion of the deployment's path to a canonical path for this purpose. However, in the case of a deployment that is a symbolic link within the deploy directory (i.e., someApp.ear is itself a symbolic link), there is no initial modification of the path to a canonical path. (Because the URL is not being set via a PropertyEditor.) So, it is stored based on the non-canonical path. But, with jboss.vfs.forceCanonical set to true, the lookup is based on the canonical path, which doesn't match.