External Drive, can't empty trash, rm sees a file, but ls -la doesn't

Question

I was clearing a music folder in my external drive and found a directory I can't delete no matter what I try.

If I put it in trash bin via GUI

The operation can’t be completed because the item “folder” is in use.

If I use rm -rf to remove it via terminal

$ rm -rf folder/
rm: folder/: Directory not empty

If I use ls -la to check its content

$ ls -la
total 512
drwxrwxrwx  1 user  staff  131072 Jan  3  2017 .
drwxrwxrwx  1 user  staff  131072 Jan  3  2017 ..

If I use rm -i * within the folder

$ rm -i *
rm: 03 - Ēlusion.mp3: No such file or directory

If I use sudo lsof +D folder/ to check if any files are opened

Nothing returns on program exit.

If I use Disk Utility to repair (first aid) disk and volume

Health check passed so no repair was initiated.

If I reboot macOS

The issue persists.

Additional info:

• I can move the folder within the drive, but not to another drive.

• I can rename the folder.

• ls -i *.mp3 returns ls: 03 - Ēlusion.mp3: No such file or directory, same as rm -i *.mp3.

• The file doesn't show up in Finder, that's confusing part, whatever filename display issue Terminal could have (I always set it to use Unicode - UTF-8), I think there are more force at play.

In response to questions, nope, ls -ib doesn't return anything.

$ ls -i
$ ls -ib
$ ls -laib
total 512
2762318 drwxrwxrwx  1 user  staff  131072 Jan  3  2017 .
2685260 drwxrwxrwx  1 user  staff  131072 Jan  3  2017 ..

---

So apparently there is something in it but ls -la couldn't see it, while rm -i is being weird with filename?

get info via GUI context menu did confirm there is 1 item in the folder, but with zero byte, and certainly doesn't show up in finder.

I am not sure what to do at this point. Help much appreciated!

(Using 10.13.4 + ExFAT on external drive)

Answer 1

The problem appears to be caused by a file named 03 - Ēlusion.mp3 located within the directory named folder.

Because Terminal.app is unable to render diacritical marks in file names--well, it is, but that's beyond the scope of providing the simplest solution for you--it hides its failure by hiding the filename (something unheard of by me before now; perhaps its High Sierra's changes to /.file, /.volfs and 64-bit inodes? Wait-- never mind; your edit to your question tell me I misunderstood you.) Anyway, the file's existence is known, along with the ironical contention by the Finder that it doesn't exist. Obviously, it does. Here's how to change that:

First, determine the file's inode number. In Terminal.app, cd to the directory "folder" and issue this command: ls -i *.mp3

Copy the number string of the inode provided in the left-hand column of the response, which will be something like

12345678 03 - E ̄lusion.mp3

--and put it into this command, which will rename it to something the terminal can render correctly:

find . -inum 12345678 -exec mv {} deletemenow \;

--giving you the file "deletemenow" in the folder "folder," both of which you may dispose of in whatever way best suits your fancy.

Answer 2

It took me a long time to come to this summary, but I think it's the definitive answer.

The cause of my issue is a well-known one:

OS X is the odd one out, both in that it normalizes file names and in that it uses NFD instead of the more common NFC.

Historically (not that old, pre 10.11 era), OS X + HFS+ enforces NFD form on all filenames, and you will only get NFD result from commands and system calls.

Then things starts to change, in 10.11, some system call results are normalized to NFC, which puts it inline with Windows and Linux, but at the expense of breaking some programs that expect NFD on OS X.

But since the introduction of macOS 10.13 + AFPS, the behavior changes again: Apple decides it wants to normalize to NFD on display and system calls, but leave the original filenames as it is (so both NFC and NFD are supported, but if you select the filename in Finder or copy ls result in Terminal, you get NFD form).

This is all great, until you put a file with NFD filename in an external drive using exFAT (as it's the only cross-macOS/Windows format with 4GB+ file size support): macOS 10.13 somehow believe your file must be in NFC format, so it bugged out.

In fact, here is a quick test, I have a folder in Windows on my exFAT drive with 3 files:

• test.mp3
• Ēlusion.mp3 (Ē in NFC)
• 03 - Ēlusion (Ē in NFD)

(You can copy the exact unicode here)

When I mount them on my macOS, this is what I see:

and ls -laib result:

$ ls -laib
total 46592
2762318 drwxrwxrwx  1 user  staff    131072 Jan  3  2017 .
2685260 drwxrwxrwx  1 user  staff    131072 Jan  3  2017 ..
1572961 -rwxrwxrwx  1 user  staff  11672464 Aug 23  2014 Ēlusion.mp3
1572871 -rwxrwxrwx  1 user  staff  11672464 Aug 23  2014 test.mp3

As you can see, the NFC file is present but NFD file is missing.

Even if you are aware of the NFC/NFD problem on OS X, you might not expect exFAT external drive to face this issue in the opposite way (NFC is fine, but NFD is pant-on-fire).

But what could have caused my music file to use NFD filename in the first place:

• I originally downloaded this music file on 10.9/10.10 with an older Mac, which enforces NFD filename.
• At some point I move them away to a Windows + NTFS drive, which doesn't enforce NFC/NFD, so original NFD filename is preserved.
• Now I want to move this file back to my macOS 10.13 + APFS using an exFAT drive (exFAT supports the same UTF-16 convention as NTFS).
• Hell break loose.

I could have copied the file via networked drive or TeamViewer, and it would be fine, but exFAT is triggering this bug on macOS.

Lessons:

• Unicode filename is still a threat.
• You actually need an Windows/Linux to fix this issue (if the situation is your file are on an exFAT external drive).