VOP_COPY_FILE_RANGE(9)

✨ VOP_COPY_FILE_RANGE(9) ✨

okay so welcome to the manual page for VOP_COPY_FILE_RANGE(9) from the Kernel Developer's Manual — grab a lil snack bestie, we're getting into it 🫶

---

💖 NAME 💖

VOP_COPY_FILE_RANGE — copy a byte range within a file or from one file to another in a single file system or between multiple file systems 💫

---

🌸 SYNOPSIS 🌸

#include <sys/param.h>
#include <sys/vnode.h>

int
VOP_COPY_FILE_RANGE(struct vnode *invp, off_t *inoff,
    struct vnode *outvp, off_t *outoff, size_t *len, unsigned int flags,
    struct ucred *incred, struct ucred *outcred,
    struct thread *fsize_td);

---

🦋 DESCRIPTION 🦋

so this entry point literally copies a byte range from one regular file to another, or within one file in a single file system. <pink>invp</pink> and <pink>outvp</pink> can refer to the same file — and for this case, the byte ranges defined by *inoff, *outoff and *len will not overlap, okay? no chaos 💅

the arguments are:

• invp — the vnode of the input file, aka where the bytes are coming from 💖
• inoff — a pointer to the file offset for the input file
• outvp — the vnode of the output file, aka where the bytes are going 🎀
• outoff — a pointer to the file offset for the output file
• len — a pointer to the byte count for the copy
• flags — flags, and bestie they should be set to 0 for now 🫶
• incred — the credentials used to read invp
• outcred — the credentials used to write outvp
• fsize_td — the thread pointer to be passed to vn_rlimit_fsize(). this will be NULL for a server thread without limits, such as for the NFS server, or curthread otherwise ✨

on entry and on return, the <pink>inoff</pink> and <pink>outoff</pink> arguments point to the locations of the file offsets. these file offsets should be updated by the number of bytes copied. the <pink>len</pink> argument points to the location that stores the number of bytes to be copied. upon a successful return <pink>len</pink> will be updated to the number of bytes actually copied — normally this will be the number of bytes requested to be copied, however a copy of fewer bytes than requested is permitted. this does not necessarily indicate that the copy reached EOF on the input file. however, if the value pointed to by the <pink>len</pink> argument is zero upon a successful return, it indicates that the offset pointed to by <pink>inoff</pink> is at or beyond EOF on the input file. iykyk 😭

---

🔒 LOCKS 🔒

heads up: the vnode are unlocked on entry and must be unlocked on return — no cap. also the byte ranges for both <pink>invp</pink> and <pink>outvp</pink> should be range locked when this call is done. periodt 💅

---

⭐ RETURN VALUES ⭐

zero is returned on success — slay 🎉 otherwise an error code is returned 😭

---

💀 ERRORS 💀

• [EFBIG] — if the copy exceeds the process's file size limit or the maximum file size for the file system invp and outvp reside on
• [EINTR] — a signal interrupted the VOP call before it could be completed
• [EIO] — an I/O error occurred while reading/writing the files
• [EINTEGRITY] — corrupted data was detected while reading/writing the files
• [ENOSPC] — the file system is full

---

🌈 SEE ALSO 🌈

vn_rdwr(9), vnode(9)

---

and that's the whole vibe!! this iconic page is brought to you by Debian, dated March 30, 2020 — gonna go touch some grass now, bestie 🧚💜