hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Wang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5021) FileSystem#delete and FileSystem#rename should operate on symlinks, not their targets
Date Thu, 25 Jul 2013 21:37:51 GMT

    [ https://issues.apache.org/jira/browse/HDFS-5021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720099#comment-13720099

Andrew Wang commented on HDFS-5021:

Hey Colin,

These cases are covered by our existing symlink tests, and I wrote the below test program
using the Java API directly which seemed to work okay:

import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FSDataOutputStream;

public class TestBadFileMaker {
  public static void main(String... args) throws Exception {
    Configuration conf = new Configuration();
    final FileSystem fs = FileSystem.get(conf);

    System.out.println("Supports symlinks: " + fs.supportsSymlinks());
    Path target = new Path("/target");
    Path link = new Path("/link");
    Path newlink = new Path("/newlink");

    fs.createSymlink(target, link, false);
    System.out.println("link: " + fs.getFileLinkStatus(link).getPath());
    System.out.println("link target: " + fs.getLinkTarget(link));

    fs.rename(link, newlink);
    System.out.println("newlink: " + fs.getFileLinkStatus(newlink).getPath());
    System.out.println("newlink target: " + fs.getLinkTarget(newlink));


Do you think it's just an issue with the FsShell? Things definitely behave wonky there.
> 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

View raw message