GETFSENT(3)

NAME
getfsent, getfsspec, getfsfile, setfsent, endfsent - get file system descriptor file entry

LIBRARY
Standard system libraries.

SYNOPSIS
#include <fstab.h>
struct fstab *
getfsent(void);
struct fstab *
getfsspec(const char *spec);
struct fstab *
getfsfile(const char *file);
int
setfsent(void);
void
endfsent(void);

DESCRIPTION
The getfsent(), getfsspec(), and getfsfile() functions each return a pointer to an object with the following structure containing file system descriptions from the directory systems consulted by the opendirectoryd daemon. This will include records from the local /etc/fstab file.

    struct fstab {
    	char	*fs_spec;	/* block special device name */
    	char	*fs_file;	/* file system path prefix */
    	char	*fs_vfstype;	/* File system type, ufs, nfs */
    	char	*fs_mntops;	/* Mount options ala -o */
    	char	*fs_type;	/* FSTAB_* from fs_mntops */
    	int	fs_freq;	/* dump frequency, in days */
    	int	fs_passno;	/* pass number on parallel fsck */
    };

The fields have meanings described in fstab(5).

The getfsspec() and getfsfile() functions search in available directory services for a matching special file name or file system file name.

For programs wishing to read the entire database, getfsent() searches all available directory services on it's first invocation. It caches the returned entries in a list and returns fstab entries one at a time.

The setfsent() and endfsent() functions clear the cached results from a previous getfsent() call.

Entries in the /etc/fstab file with a type field equivalent to FSTAB_XX are ignored.

RETURN VALUES
The getfsent(), getfsspec(), and getfsfile() functions return a NULL pointer on EOF or error. The setfsent() function returns 0 on failure, 1 on success. The endfsent() function returns nothing.

FILES
/etc/fstab

SEE ALSO
opendirectoryd(8), fstab(5).

HISTORY
The getfsent() function appeared in 4.0BSD; the endfsent(), getfsfile(), getfsspec(), and setfsent() functions appeared in 4.3BSD.

BUGS
The data space used by these functions is thread-specific; if future use requires the data, it should be copied before any subsequent calls to these functions overwrite it.