RFC: What should a copy_file_range(2) syscall do by default?

Sean Eric Fagan sef at kithrup.com
Sun Jun 23 00:02:50 UTC 2019

>>Alan mentioned locking, which does buy you something, but it also means
>>*locking the file while it is being copied*.  Which, for large files, is not
>>so great.  I also don't think you can call any large copy atomic, unless
>>you're using a signle transaction for the entire copy.
>I tried posting w.r.t. atomicity and didn't get a lot of responses.
>However, although
>kib@ didn't exactly say it should be the case, he did point out that FreeBSD has
>traditionally ensured atomicity of file updates for syscalls and felt
>that was a good
>thing. As such, I've done the range locking of both files and created
>new primitives
>to do that while avoiding deadlock.

If the source file is locked, then it's easy to create a DOS against editing
by anyone who can read the file.

More information about the freebsd-fs mailing list