[
https://issues.apache.org/jira/browse/HADOOP-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027018#comment-13027018
]
John George commented on HADOOP-7236:
-------------------------------------
Overall the code looks good. Minor comments -
The mkdirs() in PathData.java file: I understand that it was added to help move
FsShell to FileContext in an easier way. Since it looks like it might be out of
place being in PathData.java, would it make sense to instead move it to
Mkdirs.java. I understand that "fs" was moved to PathData to avoid the callers
from having to deal/know about the "fs", but to me it looks better than having
to call mkdirs() from PathData.java.
In the following code:
{quote}
+ stats.length == 1
+ &&
+ stats[0].getPath().equals(fs.makeQualified(globPath)))
+ {
+ // if the fq path is identical to the pattern passed, use the pattern
+ // to initialize the string value
+ items = new PathData[]{ new PathData(fs, pattern, stats[0]) };
{quote}
What happens in cases where stats.length == 1, but the globPath is just a
"pattern" and not identical to the path? Would you run in to the same issue?
Can you possibly use stats[0].getPath().toUri().getPath() (not pretty either)
to obtain the path? Am not sure if it returns what you want it to return, but
just throwing it out there....
Very minor comment: In some places "String thePath" is used while in some other
places "String thePathString" and "Path thePath". Could thePathString be used
for String and thePath be used for Path?
> Refactor FsShell's mkdir
> ------------------------
>
> Key: HADOOP-7236
> URL: https://issues.apache.org/jira/browse/HADOOP-7236
> Project: Hadoop Common
> Issue Type: Improvement
> Components: fs
> Affects Versions: 0.23.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Attachments: HADOOP-7236.patch
>
>
> Need to refactor tail to conform to new FsCommand class.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
