copy_file_range(2)

💖 copy_file_range — the man page, but make it make sense 💖

okay bestie, so this is the copy_file_range(2) page from the System Calls Manual, and it's literally about copying a range of data from one file to another. that's the whole vibe. let's get into it 🦋

---

✨ NAME ✨

copy_file_range — Copy a range of data from one file to another

---

🌸 LIBRARY 🌸

Standard C library (libc, -lc) — yeah she lives in libc, no surprise there 💅

---

🎀 SYNOPSIS 🎀

#define _GNU_SOURCE
#define _FILE_OFFSET_BITS 64
#include <unistd.h>

ssize_t copy_file_range(int fd_in, off_t *_Nullable off_in,
                        int fd_out, off_t *_Nullable off_out,
                        size_t size, unsigned int flags);

---

🦋 DESCRIPTION 🦋

so the copy_file_range() system call does an in-kernel copy between two file descriptors. and that's the slay part — it skips the whole extra cost of shuffling data out of the kernel into user space and then back into the kernel again. no cap, it's giving efficiency 👑

it copies up to size bytes of data from the source file descriptor fd_in to the target file descriptor fd_out, and it overwrites any data that already exists inside the requested range of the target file. periodt.

here's how the semantics go for off_in — and the same statements apply to off_out:

• if off_in is NULL, then bytes get read from fd_in starting from the file offset, and the file offset gets adjusted by however many bytes were copied.
• if off_in is not NULL, then off_in must point to a buffer that says the starting offset where bytes from fd_in will be read. the file offset of fd_in does not change, but off_in gets adjusted appropriately.

fd_in and fd_out can refer to the same file — same girl, same file 🙈 — but if they do, the source and target ranges are not allowed to overlap. that's the rule, don't break it.

and the flags argument? it exists purely to allow for future extensions. currently it must be set to 0. that's it, that's the whole job 💀

lowkey a whole syscall whose entire flags value is 0. iconic.

---

🔥 RETURN VALUE 🔥

on a successful completion, copy_file_range() returns the number of bytes copied between the files. and heads up: that can totally be less than the size you originally requested. if the file offset of fd_in is at or past the end of file, no bytes are copied at all, and copy_file_range() returns zero. zero bytes, zero problems 🫶

on error, copy_file_range() returns -1 and errno gets set to indicate the error.

---

👑 ERRORS 👑

• EBADF — one or more file descriptors are not valid.
• EBADF — fd_in is not open for reading; or fd_out is not open for writing.
• EBADF — the O_APPEND flag is set for the open file description (see open(2)) referred to by the file descriptor fd_out.
• EFBIG — an attempt was made to write at a position past the maximum file offset the kernel supports.
• EFBIG — an attempt was made to write a range that exceeds the allowed maximum file size. and btw, the maximum file size differs between filesystem implementations and can be different from the maximum allowed file offset.
• EFBIG — an attempt was made to write beyond the process's file size resource limit. this may also result in the process receiving a SIGXFSZ signal. 😭
• EINVAL — the flags argument is not 0.
• EINVAL — fd_in and fd_out refer to the same file and the source and target ranges overlap.
• EINVAL — either fd_in or fd_out is not a regular file.
• EIO — a low-level I/O error occurred while copying.
• EISDIR — either fd_in or fd_out refers to a directory.
• ENOMEM — out of memory.
• ENOSPC — there is not enough space on the target filesystem to complete the copy.
• EOPNOTSUPP — (since Linux 5.19) the filesystem does not support this operation.
• EOVERFLOW — the requested source or destination range is too large to represent in the specified data types.
• EPERM — fd_out refers to an immutable file.
• ETXTBSY — either fd_in or fd_out refers to an active swap file.
• EXDEV — (before Linux 5.3) the files referred to by fd_in and fd_out are not on the same filesystem.
• EXDEV — (since Linux 5.19) the files referred to by fd_in and fd_out are not on the same filesystem, and the source and target filesystems are not of the same type, or do not support cross-filesystem copy.

not all of those are your fault, some of them are just the filesystem not being supportive. we've all been there 💅

---

🌈 VERSIONS 🌈

a major rework of the kernel implementation happened in Linux 5.3. the parts of the API that weren't clearly defined got clarified, and the API bounds are checked much more strictly than they were on earlier kernels. glow-up fr fr ✨

since Linux 5.19, cross-filesystem copies can be achieved when both filesystems are of the same type, and that filesystem implements support for it. see BUGS for the behavior prior to Linux 5.19.

and listen: applications should target the behavior and requirements of Linux 5.19, which was also backported to earlier stable kernels. so that's the version to write against, bestie 🎀

---

💜 STANDARDS 💜

Linux, GNU.

---

🕰️ HISTORY 🕰️

Linux 4.5.

before glibc 2.30 — starting with glibc 2.27 — the glibc wrapper function provided a user-space fallback implementation for when the kernel didn't implement this system call. since glibc 2.30, that fallback has been removed; the function now fails with ENOSYS if the kernel lacks support for copy_file_range(). rip fallback, you did your best 🫡

---

💅 NOTES 💅

if fd_in is a sparse file, then copy_file_range() may expand any holes existing in the requested range. so users may benefit from calling copy_file_range() in a loop, and using the lseek(2) SEEK_DATA and SEEK_HOLE operations to find the locations of data segments. that's the move 🧚

copy_file_range() gives filesystems an opportunity to implement "copy acceleration" techniques, such as the use of reflinks (i.e., two or more inodes that share pointers to the same copy-on-write disk blocks) or server-side-copy (in the case of NFS). it's giving cloned inodes, shared blocks, we love to see it 🔥

_FILE_OFFSET_BITS should be defined to be 64 in code that uses non-null off_in or off_out or that takes the address of copy_file_range, if that code is intended to be portable to traditional 32-bit x86 and ARM platforms where off_t's width defaults to 32 bits. write it down, you'll forget iykyk 📝

---

💀 BUGS 💀

in Linux 5.3 to Linux 5.18, cross-filesystem copies were implemented by the kernel if the operation wasn't supported by individual filesystems. however, on some virtual filesystems, the call failed to copy while still reporting success. 💀💀💀 it lied. it said yes and did nothing. the audacity.

so if you're on those kernels and something looks suspiciously fine — double check it, bestie. not me trusting a successful return on a virtual filesystem 🙈

---

🌟 EXAMPLES 🌟

here's the whole thing, copy-paste ready:

#define _GNU_SOURCE
#define _FILE_OFFSET_BITS 64
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

int
main(int argc, char *argv[])
{
    int          fd_in, fd_out;
    off_t        size, ret;
    struct stat  stat;

    if (argc != 3) {
        fprintf(stderr, "Usage: %s <source> <destination>\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    fd_in = open(argv[1], O_RDONLY);
    if (fd_in == -1) {
        perror("open (argv[1])");
        exit(EXIT_FAILURE);
    }

    if (fstat(fd_in, &stat) == -1) {
        perror("fstat");
        exit(EXIT_FAILURE);
    }

    size = stat.st_size;

    fd_out = open(argv[2], O_CREAT | O_WRONLY | O_TRUNC, 0644);
    if (fd_out == -1) {
        perror("open (argv[2])");
        exit(EXIT_FAILURE);
    }

    do {
        ret = copy_file_range(fd_in, NULL, fd_out, NULL, size, 0);
        if (ret == -1) {
            perror("copy_file_range");
            exit(EXIT_FAILURE);
        }

        size -= ret;
    } while (size > 0 && ret > 0);

    close(fd_in);
    close(fd_out);
    exit(EXIT_SUCCESS);
}

see the do { } while (size > 0 && ret > 0); loop? that's the little dance you gotta do, because a single call can return fewer bytes than you asked for. keep going till it's done, main character energy only 👑

---

🌸 SEE ALSO 🌸

• lseek(2)
• sendfile(2)
• splice(2)

---

and that's the whole page, bestie!! this was Linux man-pages 6.20, dated 2026-05-14, and it's the copy_file_range(2) girlies' moment to shine. go copy some ranges (in-kernel, overlapping-free, flags set to 0) and slay 🎀💖✨