hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wei-Chiu Chuang (JIRA)" <j...@apache.org>
Subject [jira] [Reopened] (HADOOP-13508) FsPermission string constructor does not recognize sticky bit
Date Tue, 13 Dec 2016 20:21:58 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-13508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Wei-Chiu Chuang reopened HADOOP-13508:

I am reopening this issue to backport the fix to branch-2.

Please shout out if you think this is incompatible change (e.g. downstream applications that
depends on existing semantics). Thanks.

> FsPermission string constructor does not recognize sticky bit
> -------------------------------------------------------------
>                 Key: HADOOP-13508
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13508
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: Atul Sikaria
>            Assignee: Atul Sikaria
>             Fix For: 3.0.0-alpha2
>         Attachments: HADOOP-13508-1.patch, HADOOP-13508-2.patch, HADOOP-13508.003.patch,
HADOOP-13508.004.patch, HADOOP-13508.005.patch, HADOOP-13508.006.patch, HADOOP-13508.branch-2.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

To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org

View raw message