Ghost files—I don't know what else to call them.

I have an external drive which the system refuses to make writable. Most of the files on it are already on my internal drive. To save time and space, I made a list of the files that aren't and wrote a script to create the directories and copy the files. I included some debugging printouts in the script.

mkdir -p "~/tempdir/PATH" gives no error message.

echo "~/tempdir/PATH" shows the path is correct

cp "DISK/PATH/FILE" "~/tempdir/PATH/FILE" says "DISK/PATH/FILE" doesn't exist, yet

wc "~/tempdir/PATH/FILE" shows a reasonable size for the type of file. But immediately after,

ls -la "~/tempdir/PATH/FILE" says no such file or directory and Finder agrees that the top level of PATH is not in tempdir

This inconsistency repeats for every file in the list. chmod -RN, xattr -rc, and such were used to ensure it wasn't a permissions issue (even though there were no permission error messages).

I didn't know how to turn off "oh-my-zsh" so I went to bash and the script did what was expected.  So my guess is that "oh-my-zsh" has aliased one or more of the commands to behave very weirdly.

HOW is it possible in zsh+"oh-my-zsh" for cp to say the source doesn't exist, yet wc is able to read the destination in a file Finder says isn't there? And then for ls to agree that the destination doesn't exist?

MacOS 12.5 / zsh with "oh-my-zsh"

Re. the following, the 5TB partition (disk8) appears later in the list with its name. fsck & Disk Utility & Time Machine have no problem with it. Any attempt to delete files not needed on 3TB gets "read-only file system". sudo mount -w fails whether or not the volume is mounted. fsck & Disk Utility show errors that are uncorrected.enter image description here

UPDATE: in bash, the errors that zsh+"oh-my-zsh" gets on every file do not happen on most files, but still happen on five or ten percent! (same script)

UPDATE TWO: Even though the error messages are not there for most (not all) of the files and paths in bash, find says that none of the files are there, and only one of the bottom level directories!

UPDATE 3: I discovered that the shell created a directory called "~" instead of expanding it. I knew that $ variables were expanded inside double quotes, but didn't know that ~ isn't. (I think that inconsistency was a bad design choice, but we're stuck with it now.) Came here to mention it as a solution and I see that it is already in a comment. Anyway, that's where my "ghost files" went.

  • 1
    Have you tried zsh without oh-my-zsh or bash?
    – mmmmmm
    Aug 8, 2022 at 7:14
  • What is the format of the external drive? What do you mean by "the system refuses to make [the external drive] writable"?
    – jaume
    Aug 8, 2022 at 8:01
  • There have been 3rd-party data recovery programs for HFS for ages, and some now for APFS. And one open source project claims to repair HFS volumes. I don't get why Apple's fsck still can't correct problems it is able to describe in detail.
    – WGroleau
    Aug 8, 2022 at 14:45
  • 1
    Apple takes a conservative stance. If fsck can’t guarantee a sane directory, it goes read only so you know to use a different tool or save the data with a backup. Do other disks throw file system errors when you repair them from this Mac?
    – bmike
    Aug 8, 2022 at 16:06

1 Answer 1


~ is not expanded inside quotes. So take that part of the path out of the quotes. Change.

mkdir -p "~/tempdir/PATH"


mkdir -p ~/"tempdir/PATH"
  • Another alternative is to use $HOME instead of ~.
    – jrw32982
    Aug 9, 2022 at 21:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .