[
https://issues.apache.org/jira/browse/HDFS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eli Collins updated HDFS-245:
-----------------------------
Attachment: symlink23-common.patch
symlink23-hdfs.patch
Hey Sanjay,
Thanks for taking a look.
bq. * Add final to parameters of the new methods you have added.
Fixed.
bq. * GetLinkTarget() - should this be public?
Good catch, made this protected.
bq. * Resolve() checks isUriPathAbsolute(). Actually you also need to check
that the the path is fully qualified (ie has a scheme). So if a Slash-relative
path name is returned (a mistake in file system impl) the patch will
*incorrectly* resolve it relative to the FileContext's default filesystem (ie
its Slash). The file system should have resolved it internally in the first
place. Hence it would be correct (but inefficient) for the client side to send
this back to the file system in which the symlink occurred; we should simple
report this an error rather then send it back to the file system.
Good point, createSymlink in FileContext now makes the link target fully
qualified. I added tests to TestLink that use fully qualified paths for both
the link and the target. I also added an isFullyQualified method to Path (and
tests to TestPath) and updated the comment for isAbsolute to match the
implementation (which looks correct).
Note that a slash-relative path being return is currently not a mistake in the
file system impl. as the client handles all UnresolvedPathExceptions. Making
the NN transparently resolve links when the target is in its namespace is
definitely a worthwhile optimization. Need to add more tests first.
bq. * Why pass the "this" as a parameter to resolve(this, path) - the
FileContext is the "this" instance any way.
Not following, resolve is a method of FSLinkResolver not FileContext.
Thanks,
Eli
> Create symbolic links in HDFS
> -----------------------------
>
> Key: HDFS-245
> URL: https://issues.apache.org/jira/browse/HDFS-245
> Project: Hadoop HDFS
> Issue Type: New Feature
> Reporter: dhruba borthakur
> Assignee: dhruba borthakur
> Attachments: 4044_20081030spi.java, designdocv1.txt, designdocv2.txt,
> HADOOP-4044-strawman.patch, symlink-0.20.0.patch, symLink1.patch,
> symLink1.patch, symLink11.patch, symLink12.patch, symLink13.patch,
> symLink14.patch, symLink15.txt, symLink15.txt, symlink16-common.patch,
> symlink16-hdfs.patch, symlink16-mr.patch, symlink17-common.txt,
> symlink17-hdfs.txt, symlink18-common.txt, symlink19-common-delta.patch,
> symlink19-common.txt, symlink19-common.txt, symlink19-hdfs-delta.patch,
> symlink19-hdfs.txt, symlink20-common.patch, symlink20-hdfs.patch,
> symlink21-common.patch, symlink21-hdfs.patch, symlink22-common.patch,
> symlink22-hdfs.patch, symlink23-common.patch, symlink23-hdfs.patch,
> symLink4.patch, symLink5.patch, symLink6.patch, symLink8.patch, symLink9.patch
>
>
> HDFS should support symbolic links. A symbolic link is a special type of file
> that contains a reference to another file or directory in the form of an
> absolute or relative path and that affects pathname resolution. Programs
> which read or write to files named by a symbolic link will behave as if
> operating directly on the target file. However, archiving utilities can
> handle symbolic links specially and manipulate them directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
