[
https://issues.apache.org/jira/browse/HADOOP-13508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas updated HADOOP-13508:
-----------------------------------
Attachment: HADOOP-13508.003.patch
The {{UmaskParser}} also includes symbolic patterns for {{FsPermission}}, not
just the short values supported by v2. That said, the parser doesn't seem to
recognize the sticky bit in the symbolic representation, either. The regexp
parser framework seems pretty heavy, but the bug fix can precede a rewrite.
Also updated the unit test to check for the sticky bit in octal and to verify
the symbolic constructors that work.
> FsPermission's string constructor fails on valid permissions like "1777"
> ------------------------------------------------------------------------
>
> Key: HADOOP-13508
> URL: https://issues.apache.org/jira/browse/HADOOP-13508
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Atul Sikaria
> Assignee: Atul Sikaria
> Attachments: HADOOP-13508-1.patch, HADOOP-13508-2.patch,
> HADOOP-13508.003.patch
>
>
> FsPermissions's string constructor breaks on valid permission strings, like
> "1777".
> This is because FsPermission class naïvely uses UmaskParser to do it’s
> parsing of permissions: (from source code):
> public FsPermission(String mode) {
> this((new UmaskParser(mode)).getUMask());
> }
> The mode string UMask accepts is subtly different (esp wrt sticky bit), so
> parsing Umask is not the same as parsing FsPermission.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
