[
https://issues.apache.org/jira/browse/HADOOP-10521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13981394#comment-13981394
]
Chris Nauroth commented on HADOOP-10521:
----------------------------------------
Thank you for incorporating the feedback and for listing out all the
incremental changes in this version of the patch. Just a few more thoughts:
# getfattr uses {{Enum#valueOf}} to parse the encoding. When there is no enum
value matching the string, Java throws an exception with a fairly ugly message
that propagates all the way back to the user's console. (See below.) You
might want to consider catching this and instead throwing a
{{HadoopIllegalArgumentException}} with a friendlier error message.
{code}
[chris@Chriss-MacBook-Pro:ttys002] hadoop-deploy-trunk
> hadoop-3.0.0-SNAPSHOT/bin/hdfs dfs -getfattr -n xattrname -e bogus /file1
-getfattr: No enum const class
org.apache.hadoop.fs.shell.XAttrCommands$ENCODE.BOGUS
Usage: hadoop fs [generic options] -getfattr [-R] {-n name | -d} [-e en] <path>
{code}
# Is there a reason that both {{CommandFormat}} and
{{StringUtils#popOptionWithArgument}} were used? It seems you could either
pass all the options to the {{CommandFormat}}, or handle them all one by one
with {{StringUtils#popOptionWithArgument}}, and then either way you'd have a
consistent approach to parsing all of the arguments. (Let me know if I'm
missing something.)
> FsShell commands for extended attributes.
> -----------------------------------------
>
> Key: HADOOP-10521
> URL: https://issues.apache.org/jira/browse/HADOOP-10521
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs
> Affects Versions: HDFS XAttrs (HDFS-2006)
> Reporter: Yi Liu
> Assignee: Yi Liu
> Attachments: HADOOP-10521.1.patch, HADOOP-10521.2.patch,
> HADOOP-10521.3.patch, HADOOP-10521.patch
>
>
> “setfattr” and “getfattr” commands are added to FsShell for XAttr, and these
> are the same as in Linux.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
