[
https://issues.apache.org/jira/browse/IO-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781760#action_12781760
]
Apostolos Lerios edited comment on IO-168 at 11/24/09 3:54 AM:
---------------------------------------------------------------
The issue is very close to being resolved. Attila's suggestion was near
perfect. It has the following problem though:
If File f was constructed using a relative path (e.g. new File("dir") where dir
is a directory within the current one), then getParent() will return null. So
far so good. However, if dir is a directory whose ancestors include folders
with long names (e.g. "Documents and Settings"), then under 1.6.0_14 on Windows
XP SP3, the canonical path is something like
C:\Documents and Settings\Administrator\Desktop\test\directory
And the absolute path is something like
c:\DOCUME~1\Administrator\DESKTOP\tst\directory
They are unequal, so isSymlink will return true. Which is incorrect. To avoid
this problem, we should obtain f's absolute path before we try to get its
parent. That is, inside isSymlink,
file.getParent()
should be replaced with
file.getAbsoluteFile().getParent()
And similarly file.getParentFile() should become
file.getAbsoluteFile().getParentFile().
Doing this will ensure that we'll obtain f's parent, even if f is specified
with a relative file name. This, combined with Attila's fix, will avoid
oddities like the DOS names above somewhere in the ancestral hierarchy.
was (Author: tlerios):
The issue is very close to being resolved. Attila's suggestion was near
perfect. It has the following problem though:
If File f was constructed using a relative path (e.g. new File("dir") where dir
is a directory within the current one), then getParent() will return null. So
far so good. However, if dir is a directory whose ancestors include folders
with long names (e.g. "Documents and Settings"), then under 1.6.0_14 on Windows
XP SP3, the canonical path is something like
C:\Documents and Settings\Administrator\Desktop\test\directory
And the absolute path is something like
c:\DOCUME~1\Administrator\DESKTOP\tst\directory
They are unequal, so isSymlink will return true. Which is incorrect. To avoid
this problem, we should obtain f's canonical path before we try to get its
parent. That is, inside isSymlink,
file.getParent()
should be replaced with
file.getCanonicalFile().getParent()
And similarly file.getParentFile() should become
file.getCanonicalFile().getParentFile().
Doing this will ensure that we'll obtain f's parent, even if f is specified
with a relative file name. This, combined with Attila's fix, will in turn
result in f's canonical and absolute paths having a common prefix without
oddities like the DOS names above somewhere in the ancestral hierarchy.
> Symbolic links (symlinks) followed when deleting directory.
> -----------------------------------------------------------
>
> Key: IO-168
> URL: https://issues.apache.org/jira/browse/IO-168
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 1.4
> Environment: Linux only (symlinks required for bug to manifest)
> Reporter: Apostolos Lerios
> Assignee: Niall Pemberton
> Fix For: 2.0
>
> Attachments: symlinkFix.patch
>
>
> If 'dlink' is a symbolic link to a directory 'dir', and FileUtils.forceDelete
> is called on dlink, then here is what happens:
> 1) the contents of 'dir' are emptied (the link is followed).
> 2) 'dir' continues to exist (but is empty).
> 3) 'dlink' is removed.
> The correct behavior is to simply remove 'dlink' without following it and
> thus without altering the contents of 'dir' (or 'dir' itself).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
