[
https://issues.apache.org/jira/browse/HADOOP-9652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723225#comment-13723225
]
Colin Patrick McCabe commented on HADOOP-9652:
----------------------------------------------
I have managed to isolate the problem we had with {{TestMRApps}}. The old code
stripped the fragment in {{FileSystem#resolvePath}}; the new code does not.
Here's a unit test which only passes on the previous code:
{code}
@Test (timeout = 120000)
public void testResolvePath() throws Exception {
FileSystem fs = FileSystem.get(URI.create("file:///tmp/"), new
Configuration());
URI preUri = new URI("file:///tmp#fragment");
Path pre = new Path(preUri);
Path post = fs.resolvePath(pre);
Assert.assertEquals("resolvePath did not strip the fragment",
"file:/tmp", post.toString());
}
{code}
Ultimately this comes down to {{FileSystem#getFileStatus}}, since that's what
{{resolvePath}} calls. Andrew, in your new {{getFileLinkStatusInternal}}, you
currently just put the path passed by the user directly into the {{FileStatus}}
object.
In contrast, the old code returned {{new Path(new
File(originalPath.toUri().getPath())).getPath()).makeQualified(fs.getUri(),
fs.getWorkingDirectory())}}. After all those conversions back and forth, I
think:
* everything is lost except the "path string" -- i.e. "{{/tmp}}"
* we fully qualify it
For compatibility reasons, I think we probably need to do the same-- strip off
everything but the "path string" and fully qualify. I took a quick look at the
HDFS (as opposed to LocalFileSystem) code, and it goes through a very different
path. As far as I can see, however, {{DistributedFileSystem#getFileInfo}} will
also strip the "fragment." So at least we are consistent.
> RawLocalFs#getFileLinkStatus does not fill in the link owner and mode
> ---------------------------------------------------------------------
>
> Key: HADOOP-9652
> URL: https://issues.apache.org/jira/browse/HADOOP-9652
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Colin Patrick McCabe
> Assignee: Andrew Wang
> Fix For: 2.3.0
>
> Attachments: hadoop-9452-1.patch, hadoop-9652-2.patch,
> hadoop-9652-3.patch
>
>
> {{RawLocalFs#getFileLinkStatus}} does not actually get the owner and mode of
> the symlink, but instead uses the owner and mode of the symlink target. If
> the target can't be found, it fills in bogus values (the empty string and
> FsPermission.getDefault) for these.
> Symlinks have an owner distinct from the owner of the target they point to,
> and getFileLinkStatus ought to expose this.
> In some operating systems, symlinks can have a permission other than 0777.
> We ought to expose this in RawLocalFilesystem and other places, although we
> don't necessarily have to support this behavior in HDFS.
--
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
