[
https://issues.apache.org/jira/browse/HDFS-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe resolved HDFS-5021.
----------------------------------------
Resolution: Fixed
This was actually being caused by HADOOP-9817. That bug led to the FSShell
resolving all symlinks, which in turn meant that {{hadoop fs -rm}} would remove
the target file, not the symlink itself.
> FileSystem#delete and FileSystem#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 {{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
--
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
