commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
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

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.


Mime
View raw message