[
https://issues.apache.org/jira/browse/HADOOP-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049546#comment-13049546
]
Daryn Sharp commented on HADOOP-7360:
-------------------------------------
I can address the test points. One question: If I need to construct a path of
{{testdir+"/d1/f1"}}, is this the preferred way: {{new Path(new Path(testDir,
"d1"), "f1")}}?
bq. Why did you remove testWithFsAndPath()
It's private now.
bq. [...] suggest also eliminating PathData(FileSystem, String, FileStatus) and
PathData(FileSystem, FileStatus). Basically, the status should be looked up in
the FS, not set as an argument.
{{PathData(FileSystem, FileStatus)}} was removed in the patch. Did you mean
something else?
It would be a very bad idea to remove the method {{PathData(FileSystem, String,
FileStatus)}}. It's private, and only used in cases like listStatus/globStatus
where the result is an array of {{FileStatus}}. It's used to avoid an
unnecessary re-stat of the path -- overall, this class has drastically reduced
the unnecessary re-stats occurring in FsShell.
bq. PathData(FileSystem, String) [...] becomes the primary ctor.
{{PathData(FileSystem,String,FileStatus)}} is the primary ctor because a)
removing it will cause 2X the stats, b) it extracts path from a non-null
status. The path is a final, so I can't invoke {{super(FileSystem, String)}}
and then reset the path.
bq. setStat(boolean ignoreFNF) is counter-intuitive. [...] Please call it
lookupStatus(boolean ignoreFNF) [...]
100% agreed! I'm actually surprised I did that... Either I was lacking
coffee, or slipped up an eclipse refactor...
bq. getChecksumFile(): Why is this method needed (returns PathData), vs just
using Fs.getChecksumFile() (returns Path)?
There's another change backed up behind this one that drastically simplifies
the copy commands to operate purely on PathData (which incidentally will
further reduce stats, but that's not the primary purpose). Since
{{PathData(FileSystem,String)}} is now private, I had to push it into PathData,
else I have to re-expose the private ctor which will complicate the switch to
{{FileContext}}. Since commands aren't storing the fs in temporaries, it may
be possible to just switch fs to a FileContext and generally have everything
work. Having a command monkeying around getting a raw fs for the crc file and
then instantiating thru what what should be a private ctor is a minor setback.
bq. Why is this method needed instead of just using Path.getParent()? There are
currently no callers of this new method.
There are backed up changes that depend on it (I didn't expect this jira to
languish...). Remember that everything is operating on PathData, so I can't
use Path.getParent() because I'd have to re-expose a private ctor.
The other questions doubting the need for relativity are addressed on the jira
you filed. My design goal has been to mimic a unix shell.
bq. This just begs for such mis-use
I think computer users are well enough acquainted with filesystems to know that
if you change the pwd, then relative paths are no longer valid.
> FsShell does not preserve relative paths with globs
> ---------------------------------------------------
>
> Key: HADOOP-7360
> URL: https://issues.apache.org/jira/browse/HADOOP-7360
> Project: Hadoop Common
> Issue Type: Improvement
> Components: fs
> Affects Versions: 0.23.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Attachments: HADOOP-7360.patch
>
>
> FsShell currently preserves relative paths that do not contain globs.
> Unfortunately the method {{fs.globStatus()}} is fully qualifying all returned
> paths. This is causing inconsistent display of paths.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
