[
https://issues.apache.org/jira/browse/HDFS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728446#action_12728446
]
Robert Chansler commented on HDFS-240:
--------------------------------------
For reference, here is the Zookeeper rule:
Any unicode character can be used in a path subject to the following
constraints:
* The null character (\u0000) cannot be part of a path name. (This causes
problems with the C binding.)
* The following characters can't be used because they don't display well, or
render in confusing ways: \u0001 - \u0019 and \u007F - \u009F.
* The following characters are not allowed: \ud800 -uF8FFF, \uFFF0-uFFFF,
\uXFFFE - \uXFFFF (where X is a digit 1 - E), \uF0000 - \uFFFFF.
* The "." character can be used as part of another name, but "." and ".."
cannot alone be used to indicate a node along a path, because ZooKeeper doesn't
use relative paths. The following would be invalid: "/a/b/./c" or "/a/b/../c".
* The token "zookeeper" is reserved.
> Should HDFS restrict the names used for files?
> ----------------------------------------------
>
> Key: HDFS-240
> URL: https://issues.apache.org/jira/browse/HDFS-240
> Project: Hadoop HDFS
> Issue Type: New Feature
> Reporter: Robert Chansler
>
> When reviewing the consequences of Hadoop:6017 (the name system could not
> start because a file name interpreted as a regex caused a fault), the
> discussion turned to improving the test set for file system functions by
> broadening the set of names used for testing. Presently, HDFS allows any name
> without a slash. _Should the space of names be restricted?_ If most funny
> names are unintended, maybe the user would benefit from an early error
> indication. A contrary view is that restricting names is so 20th-century.
> Should be or shouldn't we?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
