[ 
https://issues.apache.org/jira/browse/IO-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Apostolos Lerios reopened IO-168:
---------------------------------


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.

Reply via email to