Xiao Chen commented on HDFS-13363:

My suggestion is based on the following reasons:
- For regular paths, the input parameter would be resolved to the iip, and 
iip.getPath will be the same as the input. 
- For advanced cases like /.reserved/inode Daryn mentioned, as a client, 
getting an exception mentioning my input path had an exception seems more 
intuitive than getting an exception mentioning the resolved path. 
- This also won't have the security concern of unnecessarily revealing paths 
that the user doesn't have permission to - which currently one has to examine 
the code to make sure.
- Path resolution isn't free. Since this is done inside the write lock, the 
cheaper the better.

If you worry about resolving the path to the inode, maybe we can add the 
inodeid to the message. Client usually doesn't care about the inodeid though, 
since that's NN internals.

> Record file path when FSDirAclOp throws AclException
> ----------------------------------------------------
>                 Key: HDFS-13363
>                 URL: https://issues.apache.org/jira/browse/HDFS-13363
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>            Reporter: Wei-Chiu Chuang
>            Assignee: Gabor Bota
>            Priority: Minor
>         Attachments: HDFS-13363.001.patch, HDFS-13363.002.patch
> When AclTransformation methods throws AclException, it does not record the 
> file path that has the exception. Therefore even if it throws an exception, 
> we would never know which file has those invalid ACLs.
> These AclTransformation methods are invoked in FSDirAclOp methods, which know 
> the file path. These FSDirAclOp methods can catch AclException, and then add 
> the file path in the error message.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to