`Bad file descriptor` when copying using hardlink flag

When I try to link a file on macOS, I get:

$ cp -l  release-source/release/examples/stubs-1-pubsub.test.js .
cp: ./stubs-1-pubsub.test.js: Bad file descriptor

This made it seem like the copying failed, but ls shows it went fine:

$ ls -li  release-source/release/examples/stubs-1-pubsub.test.js stubs-1-pubsub.test.js
9825657 -rw-r--r--  2 carlerik  staff  1072 26 sep 16:24 release-source/release/examples/stubs-1-pubsub.test.js
9825657 -rw-r--r--  2 carlerik  staff  1072 26 sep 16:24 stubs-1-pubsub.test.js

A related post talks about this error coming from the file system, not the cp util itself. Creating a hard link using the ln command works fine, so the error must be due to something cp does that ln does not, so I fired up the console and captured messages hoping to see something. I cannot see that I do ...

Does anyone have an idea what this is caused by?

System information

❯ npx envinfo --system

  System:
    OS: macOS 13.5.2
    CPU: (12) arm64 Apple M2 Max
    Memory: 4.24 GB / 64.00 GB
    Shell: 5.2.15 - /opt/homebrew/bin/bash

❯ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk0
   1:             Apple_APFS_ISC Container disk1         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk3         2.0 TB     disk0s2
   3:        Apple_APFS_Recovery Container disk2         5.4 GB     disk0s3
Post not yet marked as solved Up vote post of oligofren Down vote post of oligofren
1.1k views

Replies

Well, that’s most definitely a bug in cp. Consider this:

% cat test/tmp.txt 
Hello Cruel World!
% cp -l test/tmp.txt .       
cp: ./tmp.txt: Bad file descriptor
% ls -li test/tmp.txt tmp.txt
204902363 -rw-r--r--@ 2 quinn  staff  19 28 Sep 10:18 test/tmp.txt
204902363 -rw-r--r--@ 2 quinn  staff  19 28 Sep 10:18 tmp.txt

It make the hard link (note that both inodes are 204902363) but it still spat out an error. Weird.

Anyway, I encourage you to file a bug about this; please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Submitted as FB13434700 using the Feedback Assistant.

Same issue happens with the "-s" flag for creating symbolic links using "cp". In MacOS 13, using "cp -s" would output a warning about "bad file descriptor", but the command will execute and exit successfully. In MacOS 14, such a command exits with an error and the target symlink is not created... Can't believe they let out such bugs in a core utility like "cp"

Add a Comment