Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

getfh(2) [debian man page]

GETFH(2)						      BSD System Calls Manual							  GETFH(2)

NAME
getfh, lgetfh -- get file handle LIBRARY
Standard C Library (libc, -lc) SYNOPSIS
#include <sys/param.h> #include <sys/mount.h> int getfh(const char *path, fhandle_t *fhp); int lgetfh(const char *path, fhandle_t *fhp); DESCRIPTION
The getfh() system call returns a file handle for the specified file or directory in the file handle pointed to by fhp. The lgetfh() system call is like getfh() except in the case where the named file is a symbolic link, in which case lgetfh() returns information about the link, while getfh() returns information about the file the link references. These system calls are restricted to the superuser. RETURN VALUES
Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error. ERRORS
The getfh() and lgetfgh() system calls fail if one or more of the following are true: [ENOTDIR] A component of the path prefix of path is not a directory. [ENAMETOOLONG] The length of a component of path exceeds 255 characters, or the length of path exceeds 1023 characters. [ENOENT] The file referred to by path does not exist. [EACCES] Search permission is denied for a component of the path prefix of path. [ELOOP] Too many symbolic links were encountered in translating path. [EFAULT] The fhp argument points to an invalid address. [EIO] An I/O error occurred while reading from or writing to the file system. HISTORY
The getfh() system call first appeared in 4.4BSD. BSD
April 6, 2004 BSD

Check Out this Related Man Page

GETFH(2)						      BSD System Calls Manual							  GETFH(2)

NAME
getfh, lgetfh -- get file handle LIBRARY
Standard C Library (libc, -lc) SYNOPSIS
#include <sys/param.h> #include <sys/mount.h> int getfh(const char *path, fhandle_t *fhp); int lgetfh(const char *path, fhandle_t *fhp); DESCRIPTION
The getfh() system call returns a file handle for the specified file or directory in the file handle pointed to by fhp. The lgetfh() system call is like getfh() except in the case where the named file is a symbolic link, in which case lgetfh() returns information about the link, while getfh() returns information about the file the link references. These system calls are restricted to the superuser. RETURN VALUES
Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error. ERRORS
The getfh() and lgetfh() system calls fail if one or more of the following are true: [ENOTDIR] A component of the path prefix of path is not a directory. [ENAMETOOLONG] The length of a component of path exceeds 255 characters, or the length of path exceeds 1023 characters. [ENOENT] The file referred to by path does not exist. [EACCES] Search permission is denied for a component of the path prefix of path. [ELOOP] Too many symbolic links were encountered in translating path. [EFAULT] The fhp argument points to an invalid address. [EIO] An I/O error occurred while reading from or writing to the file system. SEE ALSO
fhopen(2), open(2), stat(2) HISTORY
The getfh() system call first appeared in 4.4BSD. BSD
April 14, 2011 BSD
Man Page

3 More Discussions You Might Find Interesting

1. Solaris

How to read the output of snoop command?

Hi! I have run the following command: snoop -q -d e1000g0 -o /var/tmp/optima0.txt & them I am trying to read the output of it with snoop -i /var/tmp/optima0.txt, which is giving me this: # snoop -i /var/tmp/optima0.txt | more 1 0.00000 AIOPTSVR -> 10.100.4.72 TCP D=1393 S=22 Push... (8 Replies)
Discussion started by: fretagi
8 Replies

2. Solaris

NFS with a NAS: permanently inconsistent directory state across clients

Hi, I am having some NFS directory consistency problems with the below setup on a local (192.) network: 1. Different permissions (chmod) for the same NFS dir are reflected on different clients. 2. (more serious) an NFS dir created on client1 cannot be accessed on client2; this applies to some... (10 Replies)
Discussion started by: cosmojetz
10 Replies

3. Slackware

NFSd problem

Hi. Using debian 8.0 on a raspberryPI SERVER, accessing nfs from another raspberry gives quick reply. But from a slackware 14.1 SERVER on a Celeron 2Ghz dual core, is painfully slow and i cannot figure out why. Can anyone guide me? (2 Replies)
Discussion started by: dimples
2 Replies