[ 
https://issues.apache.org/jira/browse/HADOOP-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630405#action_12630405
 ] 

Doug Cutting commented on HADOOP-4108:
--------------------------------------

> public FsAction access(Path p) throws IOException { ... }

This requires an RPC per file when processing directories.  I think it's better 
to hang this method off of FileStatus, so that requests to the remote 
FileSystem can be batched for directories.

> FileSystem support for POSIX access method
> ------------------------------------------
>
>                 Key: HADOOP-4108
>                 URL: https://issues.apache.org/jira/browse/HADOOP-4108
>             Project: Hadoop Core
>          Issue Type: New Feature
>          Components: fs
>            Reporter: Pete Wyckoff
>            Assignee: Pete Wyckoff
>
> From man access:
> {code}
>  int access(const char *pathname, int mode);
> {code}
> DESCRIPTION
>        access  checks  whether  the process would be allowed to read, write 
> or test for existence of the file (or other file system object) whose name is 
> pathname.  If pathname is a symbolic link permissions of the file referred to 
> by this symbolic link are tested.
>        mode is a mask consisting of one or more of R_OK, W_OK, X_OK and F_OK.
>        R_OK, W_OK and X_OK request checking whether the file exists and has 
> read, write and execute permissions, respectively.  F_OK just requests 
> checking for the existence of the file.
>        The tests depend on the permissions of the directories occurring in 
> the path to the file, as given in pathname, and on the permissions of 
> directories and files referred to by symbolic links encountered on the way.
>        The check is done with the processâs real uid and gid, rather than 
> with the effective ids as is done when actually attempting an operation.  
> This is to allow set-UID  programs  to
>        easily determine the invoking userâs authority.
>        Only  access  bits  are checked, not the file type or contents.  
> Therefore, if a directory is found to be "writable," it probably means that 
> files can be created in the directory,
>        and not that the directory can be written as a file.  Similarly, a DOS 
> file may be found to be "executable," but the execve(2) call will still fail.
>        If the process has appropriate privileges, an implementation may 
> indicate success for X_OK even if none of the execute file permission bits 
> are set.
> RETURN VALUE
>        On success (all requested permissions granted), zero is returned.  On 
> error (at least one bit in mode asked for a permission that is denied, or 
> some other error occurred),  -1  is
>        returned, and errno is set appropriately.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to