man.bsd.lv manual page server

DESCRIPTION

Implementing rename is nontrivial. If you are doing it for a new file system, you should consider starting from tmpfs_rename() as implemented in sys/fs/tmpfs/tmpfs_rename.c and adapting it to your file system's physical operations.

Because there are so many moving parts to a rename operation, genfs_rename uses the following naming conventions:

mp (mount point)

mount point of the file system in question

fdvp (from directory vnode pointer)

directory from which we are removing an entry

fcnp (from componentname pointer)

name of entry to remove from fdvp

fde (from directory entry)

fs-specific data about the entry in fdvp

fvp (from vnode pointer)

file at the entry named fcnp in fdvp

tdvp (to directory vnode pointer)

directory to which we are adding an entry

tcnp (to componentname pointer)

name of entry to add to tdvp

tde (to directory entry)

fs-specific data about the entry in tdvp

tvp (to vnode pointer)

file previously at the entry named tcnp in tdvp, to be replaced, if any, or NULL if there was no entry before

vp (vnode pointer)

any file

dvp (directory vnode pointer)

any directory with an entry for vp

A file system mumblefs should implement various file-system-dependent parts of the rename operation in a struct genfs_rename_ops, and use genfs_rename to implement mumblefs_rename() for VOP_RENAME(9) as follows:

static const struct genfs_rename_ops mumblefs_genfs_rename_ops;

static int
mumblefs_sane_rename(
    struct vnode *fdvp, struct componentname *fcnp,
    struct vnode *tdvp, struct componentname *tcnp,
    kauth_cred_t cred, bool posixly_correct)
{
	struct mumblefs_lookup_results fulr, tulr;

	return genfs_sane_rename(&mumblefs_genfs_rename_ops,
	    fdvp, fcnp, &fulr, tdvp, tcnp, &tulr,
	    cred, posixly_correct);
}

int
mumblefs_rename(void *v)
{

	return genfs_insane_rename(v, &mumblefs_sane_rename);
}

The split between mumblefs_rename() and mumblefs_sane_rename() is designed to enable us to easily change the VOP_RENAME(9) interface, which is currently designed for a broken (hence ‘insane’) locking scheme, to a more sensible locking scheme once all the file systems have their rename operations split up thus.

The struct mumblefs_lookup_results structure is storage for information about directory entries which needs to pass from the lookups of the children (see the gro_lookup member of struct genfs_rename_ops) to the physical on-disk rename or remove operations (see the gro_rename and gro_remove members of struct genfs_rename_ops).

Callers must implement the following operations as members in a struct genfs_rename_ops structure passed to genfs_rename:

int (*gro_genealogy)(struct mount *mp, kauth_cred_t cred, struct vnode *fdvp, struct vnode *tdvp, struct vnode **intermediate_node_ret)

Walk up the directory tree from the directory vnode tdvp until hitting either fdvp or the root. If fdvp is hit, store the child of fdvp through which the path from tdvp passed in *intermediate_node_ret, referenced but unlocked. If fdvp is not hit, store NULL in *intermediate_node_ret. Return zero on success or error on failure. (Failure means file-system-specific failures, not hitting or missing fdvp.)

fdvp and tdvp are guaranteed to be distinct, nonnull, referenced, and unlocked. Since no locks are held on entry except for the file-system-wide rename lock, gro_genealogy may take any locks it pleases.

int (*gro_lock_directory)(struct mount *mp, struct vnode *vp)

Lock the directory vnode vp, but fail if it has been rmdired already. Return zero on success or error on failure.

int (*gro_lookup)(struct mount *mp, struct vnode *dvp, struct componentname *cnp, void *de, struct vnode **vpp)

Look up the entry in dvp for cnp, storing the vnode in *vpp and using de, one of the pointers passed to genfs_sane_rename, to store information about the directory entry as needed by the file system's gro_rename operation, and return zero. If there is no such entry, return error.

dvp is guaranteed to be locked, and the vnode returned in *vpp must be unlocked. However, gro_lookup may temporarily lock the vnode without causing deadlock.

bool (*gro_directory_empty_p)(struct mount *mp, kauth_cred_t cred, struct vnode *vp, struct vnode *dvp)

Return true if the directory vnode vp is empty. The argument dvp is the parent of vp, as required for this check by some file systems.

dvp and vp are guaranteed to be distinct, nonnull, referenced, and locked.

int (*gro_rename_check_possible)(struct mount *mp, struct vnode *fdvp, struct vnode *fvp, struct vnode *tdvp, struct vnode *tvp)

Return zero if the file system might allow the rename independent of credentials, or error if not. This should check, for example, any immutability flags in the vnodes in question, and should use genfs_ufslike_rename_check_possible() for file systems similar to UFS/FFS.

fdvp and tdvp may be the same; every other pair of vnodes is guaranteed to be distinct. tvp may be NULL; every other vnode is guaranteed to be nonnull. All three or four vnodes are guaranteed to be referenced and locked.

int (*gro_rename_check_permitted)(struct mount *mp, kauth_cred_t cred, struct vnode *fdvp, struct vnode *fvp, struct vnode *tdvp, struct vnode *tvp)

Return zero if the file system allows the rename given the credentials cred, or error if not. This should check, for example, the ownership and permissions bits of the vnodes in question, and should use genfs_ufslike_rename_check_permitted() for file systems similar to UFS/FFS.

fdvp and tdvp may be the same; every other pair of vnodes is guaranteed to be distinct. tvp may be NULL; every other vnode is guaranteed to be nonnull. All three or four vnodes are guaranteed to be referenced and locked.

int (*gro_rename)(struct mount *mp, kauth_cred_t cred, struct vnode *fdvp, struct componentname *fcnp, void *fde, struct vnode *fvp, struct vnode *tdvp, struct componentname *tcnp, void *tde, struct vnode *tvp)

Perform the physical file system rename operation, report any knotes, and purge the namecache entries. Return zero on success or error on failure. All file-system-independent error cases have been handled already.

File systems using fstrans(9) should use fstrans_start(9) and fstrans_done(9) here. fde and tde are the pointers that were supplied to genfs_sane_rename() and got passed to the gro_lookup operation to find information about directory entries.

This may use genfs_rename_knote() to report any knotes, if the various file-system-dependent routines it uses to edit links don't do that already. This should use genfs_rename_cache_purge() to purge the namecache.

fdvp and tdvp may be the same; every other pair of vnodes is guaranteed to be distinct. tvp may be null; every other vnode is guaranteed to be nonnull. All three or four vnodes are guaranteed to be referenced and locked.

int (*gro_remove_check_possible)(struct mount *mp, struct vnode *dvp, struct vnode *vp)

Return zero if the file system might allow removing an entry in dvp for vp independent of credentials, or error if not. This should use genfs_ufslike_remove_check_possible() for file systems similar to UFS/FFS.

dvp and vp are guaranteed to be distinct, nonnull, referenced, and locked.

This, and gro_remove_check_permitted below, are for renames that reduce to a remove; that is, renaming one entry to another when both entries refer to the same file. For reasons of locking insanity, genfs_rename cannot simply call VOP_REMOVE(9) instead.

int (*gro_remove_check_permitted)(struct mount *mp, kauth_cred_t cred, struct vnode *dvp, struct vnode *vp)

Return zero if the file system allows removing an entry in dvp for vp given the credentials cred, or error if not. This should use genfs_ufslike_remove_check_permitted() for file systems similar to UFS/FFS.

dvp and vp are guaranteed to be distinct, nonnull, referenced, and locked.

int (*gro_remove)(struct mount *mp, kauth_cred_t cred, struct vnode *dvp, struct componentname *cnp, void *de, struct vnode *vp)

For a rename that is effectively a remove, perform the physical file system remove operation, report any knotes, and purge the namecache entries. Return zero on success or error on failure. All file-system-independent error cases have been handled already.

File systems using fstrans(9) should use fstrans_start(9) and fstrans_done(9) here. de is one of the pointers that were supplied to genfs_sane_rename() and got passed to the gro_lookup operation to find information about directory entries.

This should signal a NOTE_WRITE knote for dvp, and either a NOTE_DELETE or a NOTE_LINK knote for vp, depending on whether this removed the last link to it or not.

dvp and vp are guaranteed to be distinct, nonnull, referenced, and locked.

The following utilities are provided for implementing the struct genfs_rename_ops operations:

genfs_rename_knote(fdvp, fvp, tdvp, tvp)

Signal all the knotes relevant for the rename operation.

genfs_rename_cache_purge(fdvp, fvp, tdvp, tvp)

Purge any namecache entries that the rename operation invalidates.

genfs_ufslike_rename_check_possible(fdflags, fflags, tdflags, tflags, clobber, immutable, append)

Check whether the UFS/FFS-like flags of the files involved a rename allow it. Return zero if allowed or error if not.

fdflags

flags of source directory

fflags

flags of source file

tdflags

flags of target directory

tflags

flags of target file, if there is one and clobber is true, or ignored otherwise

clobber

true if there is a target file whose entry will be clobbered or false if not

immutable

bit mask for the file system's immutable bit, like the UFS/FFS IMMUTABLE

append

bit mask for the file system's append-only bit, like the UFS/FFS APPEND

genfs_ufslike_rename_check_permitted(cred, fdvp, fdmode, fduid, fvp, fuid, tdvp, tdmode, tduid, tvp, tuid)

Check whether the credentials cred are permitted by the file ownership and permissions bits to perform a rename. Return zero if permitted or error if not.

cred

caller's credentials

fdvp

source directory

fdmode

file permissions bits of fdvp

fduid

uid of the owner of fdvp

fvp

source file

fuid

uid of owner of fvp

tdvp

target directory

tdmode

file permissions bits of tdvp

tduid

uid of owner of tdvp

tvp

target file, if there is one, or NULL if not

tuid

uid of owner of tvp, if there is a target file, or ignored otherwise

genfs_ufslike_remove_check_possible(dflags, flags, immutable, append)

Check whether the UFS/FFS-like flags of the files involved a remove allow it. Return zero if allowed or error if not.

dflags

flags of the directory

flags

flags of the file in the directory

immutable

bit mask for the file system's immutable bit, like the UFS/FFS IMMUTABLE

append

bit mask for the file system's append-only bit, like the UFS/FFS APPEND

genfs_ufslike_remove_check_permitted(cred, dvp, dmode, duid, vp, uid)

Check whether the credentials cred are permitted by the file ownership and permissions bits to perform a remove. Return zero if permitted or error if not.

cred

caller's credentials

dvp

directory

dmode

file permissions bits of dvp

duid

uid of owner of dvp

vp

file in dvp

uid

uid of owner of vp