[ https://issues.apache.org/jira/browse/HDFS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eli Collins updated HDFS-245: ----------------------------- Attachment: symlink35-hdfs.patch Hey Sanjay, Thanks for the review. Latest patch attached, addresses your feedback and merges in trunk. bq. File Jira to resolve dot relative and volume-root relative names locally in HDFS (this Jira can be completed later) Filed HDFS-932. bq. explicitly declare the unresolvedLinkException in methods that throw them- we are moving towards declaring all exceptions (see HDFS-717). ClientProtocol, Namenode, FSNamesystem, etc Done. I had to modify quite a few functions both in hdfs and common since the UnresolvedLinkException flows all the way up to FileContext. I left the tests as is, I also didn't modify FileSystem. bq. UnresolvedPathException, suggestion: adding a method called "getUnresolvedPath for completeness. Done. bq. createSymlinkXXX -don't pass in permission object as parameter - it suggests that permissions matter for symlinks Done. I left the permissions as default since INodes do not support null PermissionStatus or PermissionStatus' created with a null FsPermission. Currently links are rwx everyone so access is checked on the link target. And like files accessed to the links themselves should be subject to the containing directory's permissions. I started to modify TestDFSPermission to cover this, which requires converting the test to use FileContext, and just converting it to use FileContext caused some of the tests to fail, which I'm looking into, if you don't mind will address in a follow-on jira. I filed HDFS-876 for porting tests over to FileContext a while back and HDFS-934 to extend those for additional coverage after they've been ported. bq. FSDirectory#addToParent - if not a symlink, then pass null instead of a null string. The symlink value needs to be a string since we serialize it to image/edit log, ie readString and writeString don't support nulls. bq. getExistingPathINodes() typo: javadoc for param resolveLink is missing the param name Fixed. bq. Add comment that exception is thrown for symlinks occurs in the middle of the path. Done. bq. The multiple if statements with same or negation of condition - can be confusing and error prone in future I rewrote this to use just two if that read like the logic: "If the current node is a symlink then throw an UnresolvedPathException, unconditionally if we are not on the last path component, and conditionally if we are on the last path component and we want to resolve it." Think this is more clear. {code} if (curNode.isLink() && (!lastComp || (lastComp && resolveLink))) { throw new UnresolvedPathException(...) } if (lastComp || !curNode.isDirectory()) { break; } {code} bq. FSDirectory#getFileBlocks add: if (symlink) return null. Fixed. Shouldn't be executed in practice since we always complete a resolved path. bq. FSDirectory#getListing() calls getNode(srcs, false) // shouldn't resolveLink be true Fixed. FileContext#listStatus was not resolving links, fixed that. I added FileContextSymlinkBaseTest#testListStatusUsingLink to test this case. bq. FSDirectory#getPreferredBlockSize calls getNode(filename, false ) // shouldn't resolveLink be true Fixed. Looks like DFSClient#getBlockSize is the only caller and isn't covered by any unit tests (you can remove the method and compile hdfs). Filed HDFS-929 to either remove it or add a test. I replaced the throw of UnresolvedPathException in FSNameSystem, it wasn't necessary as the call to getFileINode resolves the links. There's now only a single place we throw UnresolvedPathException which was my original intent. Latest patch attached here and to HADOOP-6421. 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: Eli Collins > Attachments: 4044_20081030spi.java, designdocv1.txt, designdocv2.txt, > designdocv3.txt, HADOOP-4044-strawman.patch, symlink-0.20.0.patch, > symlink-25-hdfs.patch, symlink-26-hdfs.patch, symlink-26-hdfs.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, symlink24-hdfs.patch, symlink27-hdfs.patch, > symlink28-hdfs.patch, symlink29-hdfs.patch, symlink29-hdfs.patch, > symlink30-hdfs.patch, symlink31-hdfs.patch, symlink33-hdfs.patch, > symlink35-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.