hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-5021) FSShell delete and FSShell rename should operate on symlinks, not their targets
Date Fri, 02 Aug 2013 18:35:51 GMT

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

Colin Patrick McCabe updated HDFS-5021:
---------------------------------------

    Description: 
Currently FSShell delete and FSShell rename don't behave as expected on symlinks.  If you
have {{/a/b/c}} as a link to {{/a/b/d}}, and you try to delete {{/a/b/c}}, the target {{/a/b/d}}
will be deleted instead.  Not only is this contrary to POSIX (and pretty much every other
filesystem standard) but this gives us no way to actually delete symlinks other than deleting
the containing directory.

Let's fix this so deleting a symlink deletes the symlink itself.  It will just require not
dereferencing the last path component.  I haven't looked as closely into rename but I think
there are similar issues there

  was:
Currently {{FileSystem#delete}} and {{FileSystem#rename}} don't behave as expected on symlinks.
 If you have {{/a/b/c}} as a link to {{/a/b/d}}, and you try to delete {{/a/b/c}}, the target
{{/a/b/d}} will be deleted instead.  Not only is this contrary to POSIX (and pretty much every
other filesystem standard) but this gives us no way to actually delete symlinks other than
deleting the containing directory.

Let's fix this so deleting a symlink deletes the symlink itself.  It will just require not
dereferencing the last path component.  I haven't looked as closely into rename but I think
there are similar issues there

    
> FSShell delete and FSShell rename should operate on symlinks, not their targets
> -------------------------------------------------------------------------------
>
>                 Key: HDFS-5021
>                 URL: https://issues.apache.org/jira/browse/HDFS-5021
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: Colin Patrick McCabe
>             Fix For: 2.1.0-beta
>
>
> Currently FSShell delete and FSShell rename don't behave as expected on symlinks.  If
you have {{/a/b/c}} as a link to {{/a/b/d}}, and you try to delete {{/a/b/c}}, the target
{{/a/b/d}} will be deleted instead.  Not only is this contrary to POSIX (and pretty much every
other filesystem standard) but this gives us no way to actually delete symlinks other than
deleting the containing directory.
> Let's fix this so deleting a symlink deletes the symlink itself.  It will just require
not dereferencing the last path component.  I haven't looked as closely into rename but I
think there are similar issues there

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message