[
https://issues.apache.org/jira/browse/HADOOP-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049966#comment-13049966
]
Matt Foley commented on HADOOP-7393:
------------------------------------
Option 2 seems like the only viable approach, then.
I'll agree that getDirectoryContents() works correctly in that regards.
getPathDataForChild() doesn't seem to. Nor do I see general logic that
invalidates relative paths when the cwd does change, except maybe in the
relativize() method.
I also have to point out that (a) all the PathData i/f methods are public, not
package-private; (b) code always gets re-used for purposes not expected by the
author, and (c) the fact that set/getWorkingDirectory methods exist mean that
you can't reasonably expect them to never be called between two calls to
PathData references.
So will you humor me to the following extent? Save 'cwd' at instantiation
time, either as a Path or an absolute pathstring. Provide a method 'String
getOrigPathString()' which checks getWorkingDirectory against cwd, and returns
'string' if same, or something derived from 'cwd' + 'string' otherwise. Then
comment out the wazoo that 'string' must never be accessed directly, but always
via the getOrigPathString() method. And do it that way internally in all
PathData methods too.
Would that be acceptable? getWorkingDirectory() should only access in-memory
data structures, so it shouldn't be a big cost.
> PathData saves original string value, inviting failure when CWD changes
> -----------------------------------------------------------------------
>
> Key: HADOOP-7393
> URL: https://issues.apache.org/jira/browse/HADOOP-7393
> Project: Hadoop Common
> Issue Type: Bug
> Components: fs
> Affects Versions: 0.23.0
> Reporter: Matt Foley
>
> PathData#string stores the pathstring originally used to construct the Path,
> and returns it from various methods, apparently in an attempt to improve the
> user experience for the shell.
> However, the current working directory may change, and if so this string
> value becomes meaningless and/or incorrect in context.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
