hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Collins (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HDFS-245) Create symbolic links in HDFS
Date Tue, 23 Feb 2010 23:42:29 GMT

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

Eli Collins updated HDFS-245:
-----------------------------

    Attachment: symlink41-hdfs.patch

Hey Sanjay,

The attached patch addresses your feedback and merges with trunk. I had to resolve a bunch
of diffs with and add new code for HDFS-946 which introduced HdfsFileStatus so would be good
to check out those changes in particular.

Details:
* Added missing throws of UnresolvedLinkException to DFSClient 
* Removed UnresolvedLinkException from NameNode
* Fixed Lease#findPath per your suggestion, did the same to getCompleteBlocksTotal since it
should also not throw an UnresolvedLinkException
* Filed HADOOP-6585 and HDFS-995 to do the new FsStatus APIs and convert existing code to
the new interfaces.
* FSNameSystem#verifyParentDir now passes true for resolveLink, tests are in the base class
so will be in an upcoming common change.
* Replaced the numBlocks "> -2" check with "== -1" 
* When through whitespace changes, they should just remove trailing whitespaces now.
* Updated HDFS-995 with your suggestions for checking #isDirectory()
* I noticed INode#constructPath was using StringBuffer, changed it to use StringBuilder
* FSNamesystem#metaSave no longers throws UnresolvedSymlinkException. It just use java.io.File
for the local file so symlinks should be handled transparently by the local file system.
* Also, for those following along, we should not have to worry about UnresolvedLinkExceptions
in loadFSImage and friends because intermediate symlinks are resolved when objects are created,
so the paths that get persisted are the fully resolved ones, ie creating /link/file will persist
/dir/file so when we load the image we will call addToParent(.."/dir/file"..). This should
be more clear when volume relative symlinks are resolved internally (HDFS-932). The code asserts
on these cases.
* getLinkTarget never throws an UnresolvedLinkException, it always resolves the first symlink
in the path and ignores the remainder, so I left the throws clause as is

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, design-doc-v4.txt, 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,
symlink36-hdfs.patch, symlink37-hdfs.patch, symlink38-hdfs.patch, symlink39-hdfs.patch, symLink4.patch,
symlink40-hdfs.patch, symlink41-hdfs.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.


Mime
View raw message