[
https://issues.apache.org/jira/browse/HADOOP-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth updated HADOOP-8957:
----------------------------------
Attachment: HADOOP-8957-branch-trunk-win.2.patch
Sanjay, thank you for the feedback. Your suggestion to keep the HDFS
validation rules in the base class and let the subclasses override to turn it
off really simplified the whole change. I have attached an updated patch. Can
you take a look?
{quote}
The mounted file systems will validate the path names anyway - so is this
necessary?
{quote}
Now that the HDFS rules are back in the base class, the answer is no, it is not
necessary to do an additional pre-validation by delgating to the mounted file
system's isValidName in ViewFS. The new patch does not have the
resolveFromFSState refactoring.
{quote}
What about validating internal names (ie within the mounted) which your patch
does not.
{quote}
I agree that checking at mount table creation time (fail fast) makes the most
sense. Right now, the only such validation that occurs at initialization time
is a check for Path#isAbsoluteAndSchemAuthorityNull inside
InodeTree#createLink. Do you think additional validation rules make sense
here? If so, what would be the rules? Match HDFS validation rules? Check the
union of the validation rules for all mounted file systems, so that users see
consistent path names across the whole ViewFS? If we need enhancements here,
I'd like to suggest that we file a separate jira.
> AbstractFileSystem#IsValidName should be overridden for embedded file systems
> like ViewFs
> -----------------------------------------------------------------------------------------
>
> Key: HADOOP-8957
> URL: https://issues.apache.org/jira/browse/HADOOP-8957
> Project: Hadoop Common
> Issue Type: Bug
> Components: fs
> Affects Versions: trunk-win
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Attachments: HADOOP-8957-branch-trunk-win.2.patch, HADOOP-8957.patch,
> HADOOP-8957.patch
>
>
> This appears to be a problem with parsing a Windows-specific path, ultimately
> throwing InvocationTargetException from AbstractFileSystem.newInstance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
