# commons-issues mailing list archives

##### Site index · List index
Message view
Top
From "Apostolos Lerios (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (IO-168) Symbolic links (symlinks) followed when deleting directory.
Date Tue, 24 Nov 2009 03:56:41 GMT
```
[ 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

And the absolute path is something like

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

And the absolute path is something like

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.

> -----------------------------------------------------------
>
>                 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
>
>
>
> 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).