[jira] Reopened: (IO-168) Symbolic links (symlinks) followed when deleting directory.

["Apostolos Lerios (JIRA)" <ji...@apache.org>]

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