[
https://issues.apache.org/jira/browse/HADOOP-9652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718943#comment-13718943
]
Colin Patrick McCabe commented on HADOOP-9652:
----------------------------------------------
bq. True, I added the username check back in. The other tests are unfortunately
harder; for instance, symlink permissions are inconsistent across operating
systems, and it's unclear to me which of the user's groups is set.
Newly created files get set to the user's primary group on UNIX.
{code}
+ FileStatus status = fsImpl.getFileLinkStatus(f);
+ // FileSystem#getFileLinkStatus qualifies the link target
+ // AbstractFileSystem needs to return it plain since it's qualified
+ // in FileContext, so re-get and set the plain target
+ if (status.isSymlink()) {
+ status.setSymlink(fsImpl.getLinkTarget(f));
+ }
+ return status;
{code}
This actually highlight something that I think we might need to fix in the
FileSystem symlink support-- the fact that it's impossible to view relative
symlink paths once they are created.
Let's say I create a symlink from a -> ./b in my local HDFS.
With the new FSShell support in HDFS-4019, Hadoop displays this as:
{code}
lrwxrwxrwx - cmccabe supergroup 0 2013-07-23 15:59 /a ->
hdfs://localhost:6000/b
{code}
It seems to me that we should display relative symlinks *as* relative, rather
than absolute-izing them and adding a URI. Otherwise, if we use DistCp to copy
a cluster's data to another cluster, all the symlink targets will be wrong.
This is probably out of scope for this particular JIRA, but should we file a
follow-up?
{code}
+ if (osType == OSType.OS_TYPE_UNIX) {
+ return new String[] {
+ "bash", "-c",
+ "exec 'stat' '" + derefFlag + "c' '%s,%F,%Y,%X,%a,%U,%G,%N' '"
+ + path + "' 2>&1" };
{code}
Shouldn't this be OS_TYPE_LINUX? I don't think, for example, OpenBSD comes
with the GNU stat program. We should also really also file a follow-up bug to
remove this and move to a more portable solution when we get the green light to
drop JDK6 support.
> 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
> Attachments: hadoop-9452-1.patch, hadoop-9652-2.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
