`std::fs::copy` causes extra AppleDouble sidecar `._` files on exFAT due to `COPYFILE_ALL`

[konstin]

std::fs::copy on an exFAT drive creates ._ AppleDouble sidcar files if there are any extended attributes on files, as it uses COPYFILE_ALL. This problem was first reported in uv: astral-sh/uv#18790.

rust/library/std/src/sys/fs/unix.rs

Line 2449 in 05cda35

let flags = if writer_metadata.is_file() { COPYFILE_ALL } else { libc::COPYFILE_DATA };

This is different from python, which uses COPYFILE_DATA for shutil.copy instead:

https://github.com/python/cpython/blob/12828e5f98a47864e3f6d25fdd99c062fae28b1c/Lib/shutil.py#L319.

This is a problem extracting and then copying a directory, where there's suddenly extra files in the tree that shouldn't be there (astral-sh/uv#18790). We would like to retain the mode (specifically, the executable bit), but avoid having extra files that cause problem in a walkdir-and-copy scheme. I couldn't find any discussion on COPYFILE_ALL in #58901 (CC @ebarnard), hence I'm opening this issue.

This LLM-written script reproduces this on my macOS VM. It shows how std::fs::copy creates the sidecar file:

#!/usr/bin/env bash
# Reproducer: std::fs::copy creates ._ AppleDouble sidecar files on exFAT.
# Raw read/write and python avoid this.

WORKDIR=$(mktemp -d)
DMG="$WORKDIR/exfat.dmg"
VOL="$WORKDIR/mnt"
cleanup() { hdiutil detach "$VOL" 2>/dev/null; rm -rf "$WORKDIR"; }
trap cleanup EXIT
set -euo pipefail

mkdir -p "$VOL"
hdiutil create -size 64m -fs ExFAT -volname "EXFAT_UV" "$DMG" > /dev/null
hdiutil attach "$DMG" -mountpoint "$VOL" > /dev/null

SRC=$(mktemp)
echo "hello" > "$SRC"
xattr -w com.apple.quarantine "0081;deadbeef;test;0" "$SRC"

RDIR=$(mktemp -d)
cat > "$RDIR/main.rs" << 'EOF'
fn main() {
    let args: Vec<String> = std::env::args().collect();
    match args[1].as_str() {
        "std" => { std::fs::copy(&args[2], &args[3]).unwrap(); }
        "raw" => {
            let meta = std::fs::metadata(&args[2]).unwrap();
            let mut r = std::fs::File::open(&args[2]).unwrap();
            let mut w = std::fs::File::create(&args[3]).unwrap();
            std::io::copy(&mut r, &mut w).unwrap();
            w.set_permissions(meta.permissions()).unwrap();
        }
        _ => panic!("usage: copier std|raw <src> <dst>"),
    }
}
EOF
rustc "$RDIR/main.rs" -o "$RDIR/copier"

"$RDIR/copier" std "$SRC" "$VOL/test_std.txt"
echo "Rust std::fs::copy  → sidecar ._ files: $(find "$VOL" -name '._test_std*' | wc -l | tr -d ' ')"

"$RDIR/copier" raw "$SRC" "$VOL/test_raw.txt"
echo "Rust raw read/write → sidecar ._ files: $(find "$VOL" -name '._test_raw*' | wc -l | tr -d ' ')"

python3 -c "import shutil,sys; shutil.copyfile(sys.argv[1], sys.argv[2])" "$SRC" "$VOL/test_py.txt"
echo "Python shutil       → sidecar ._ files: $(find "$VOL" -name '._test_py*' | wc -l | tr -d ' ')"

rm -f "$SRC" && rm -rf "$RDIR"

Tested on 1.94.1, but the relevant code is in main (05cda35).

[bjorn3]

What does cp do? And using COPYFILE_DATA would break quarantine, right?

[qqgjyx]

What does cp do?

cp also creates ._ sidecars on exFAT when the source has xattrs — same behavior as std::fs::copy.

And using COPYFILE_DATA would break quarantine, right?

Yes. For uv's use case (copying package files into a venv) that's fine.

One caveat: on macOS 26 (26.3.1), COPYFILE_DATA alone may not fully solve the sidecar problem. The kernel now adds com.apple.provenance to every newly created file, and this xattr can't be removed. On exFAT, it creates ._ sidecars for any file write:

$ echo hello > /Volumes/ExFAT/test.txt
$ ls /Volumes/ExFAT/._test.txt
._test.txt  # exists — from com.apple.provenance
$ xattr -d com.apple.provenance /Volumes/ExFAT/test.txt  # no-op, comes back

Every method I tested (echo, cp, Rust std::fs::copy, Rust raw read/write, Python shutil.copyfile) produces sidecars on macOS 26 + exFAT. This may be version-specific — @konstin's VM script shows different results, possibly on an earlier macOS.

[Noratrieb]

@rustbot ping apple

[rustbot]

Hey Apple notification group! This issue or PR could use some Apple-specific
guidance. Could one of you weigh in? Thanks <3

(In case it's useful, here are some instructions for tackling these sorts of
issues).

cc @BlackHoleFox @hkratz @inflation @madsmtm @nvzqz @shepmaster @thomcc

[inflation]

We should keep its behavior constant with system cp for least surprising.