[
https://issues.apache.org/jira/browse/HDFS-6451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhiraj Butala updated HDFS-6451:
---------------------------------
Attachment: HDFS-6451.patch
Attaching one version of the fix, which introduces a function to check the
IOException type and return the NFS3Status code accordingly.
Please note that, the function returns NFS3ERR_ACCES for AccessControlException
(instead of NFS3ERR_PERM), as that gave 'Permission denied' responses on my
setup as shown below (this is also in sync with some of the discussion in HDFS
6411):
{code}
$ ls
log4j.properties loglog
$ mv log4j.properties abc
mv: cannot move `log4j.properties' to `abc': Permission denied
$ ln -s log4j.properties abc
ln: failed to create symbolic link `abc': Permission denied
$ rm log4j.properties
rm: remove write-protected regular file `log4j.properties'? y
rm: cannot remove `log4j.properties': Permission denied
{code}
Please let me know if there are any suggestions. Thank you!
> NFS should not return NFS3ERR_IO for AccessControlException
> ------------------------------------------------------------
>
> Key: HDFS-6451
> URL: https://issues.apache.org/jira/browse/HDFS-6451
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: nfs
> Reporter: Brandon Li
> Attachments: HDFS-6451.patch
>
>
> As [~jingzhao] pointed out in HDFS-6411, we need to catch the
> AccessControlException from the HDFS calls, and return NFS3ERR_PERM instead
> of NFS3ERR_IO for it.
> Another possible improvement is to have a single class/method for the common
> exception handling process, instead of repeating the same exception handling
> process in different NFS methods.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
