You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Matt Foley (JIRA)" <ji...@apache.org> on 2011/06/14 23:48:47 UTC
[jira] [Created] (HADOOP-7393) PathData saves original string
value, inviting failure when CWD changes
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
[jira] [Commented] (HADOOP-7393) PathData saves original string
value, inviting failure when CWD changes
Posted by "Daryn Sharp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049509#comment-13049509 ]
Daryn Sharp commented on HADOOP-7393:
-------------------------------------
As currently designed/implemented, I feel the premise of this jira is invalid, however I do understand the sentiment. The PathData object is only intended for internal use in FsShell. The cwd does not change during the execution of any of the commands, so the relative path is not invalidated.
bq. Like Path, convert the pathstring to an absolute pathstring. [...]
bq. Don't store #string. [...]
This would unravel the benefit. The intent of storing the string is that what you give it is +exactly+ what you get back, just like a unix shell, not a path that has been mangled. If you were to take the old FsShell and feed it an arbitrary path, you would have a hard time reliably matching the path in the output.
bq. Store the absolute path (or Path) of the CWD at instantiation time. When #string is referenced, compare the current WD to the stored WD, and if they differ, convert #string to an absolute stringpath wrt the stored WD.
I would put forth the opinion that PathData is currently doing the "right thing": relative paths are invalidated when pwd changes. At a normal shell, if you were to type {{x=foo.txt}}, {{cat $x}}, {{cd somewhere-else}}, and again {{cat $x}}, you certainly wouldn't expect the original {{foo.txt}} to be displayed. If the desire is to use PathData outside of FsShell, I could probably be swayed from this position.
My goal has been for FsShell to act and feel just like a real shell. That said, I do welcome a response.
> 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
[jira] [Commented] (HADOOP-7393) PathData saves original string
value, inviting failure when CWD changes
Posted by "Matt Foley (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (HADOOP-7393) PathData saves original string
value, inviting failure when CWD changes
Posted by "Matt Foley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049452#comment-13049452 ]
Matt Foley commented on HADOOP-7393:
------------------------------------
Three solutions might be valid:
# Like Path, convert the pathstring to an absolute pathstring. If it is desired to give the user an fs pathstring instead of URI as used by Path, then convert the relative fs pathstring into an absolute fs pathstring, and store that.
# Store the absolute path (or Path) of the CWD at instantiation time. When #string is referenced, compare the current WD to the stored WD, and if they differ, convert #string to an absolute stringpath wrt the stored WD.
# Don't store #string. Like Path, discard the pathstring after instantiation. If needed later, return Path#uri.
> 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