Strange case of truly invisible file (?) and undeletable directory on macOS I'm having issues deleting a directory on my macOS Mojave 10.14.3 system.

The filesystem is APFS and these are the symptoms:

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




$ sudo rm -rf strange/
Password:
rm: strange/: Directory not empty




$ ls -lia strange/
total 0
786499 drwxr-xr-x   3 kk  staff    96 Feb 26 18:56 .
430961 drwxr-xr-x+ 49 kk  staff  1568 Feb 26 21:50 ..




$ ls -lid strange/
786499 drwxr-xr-x  3 kk  staff  96 Feb 26 18:56 strange/


Notice that the link count for the directory is is 3. A freshly created empty directory has a link count of 2.

No other file or directory on the system has the same inode number (this was checked using sudo find / -inum 786499), and I believe that directories on APFS filesystems can't have additional hard links anyway (like they can with HFS+).

Putting the directory in the trash and emptying it returns a dialog with the text


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


However, running sudo lsof "$HOME/strange" (after returning the directory to my home directory) returns nothing, and rebooting the machine changes nothing. Using sudo lsof +L1 (listing open files with a link count of zero, i.e. deleted files kept open by some application) also does not reveal any paths under the strange directory.

The directory does not have any ACLs or extended attributes:

$ ls -lde@ strange/
drwxr-xr-x  3 kk  staff  96 Feb 26 18:56 strange/


Making a copy of the directory using the Finder creates strange copy.  This copy directory has a link count of 2 and can be deleted.  Curiously though, the "Get Info" dialog in Finder says that each directory (original and copy) contains an item (it usually reports zero items for freshly created empty directories).

$ ls -la strange*
strange:
total 0
drwxr-xr-x   3 kk  staff    96 Feb 26 23:57 .
drwxr-xr-x+ 49 kk  staff  1568 Feb 27 10:36 ..

strange copy:
total 0
drwxr-xr-x   2 kk  staff    64 Feb 26 23:57 .
drwxr-xr-x+ 49 kk  staff  1568 Feb 27 10:36 ..




Running "First Aid" using the macOS "Disk Utility" does not change anything (returns "Successful" at the end). This regardless of whether this is done on the live system or in Rescue Mode.

Running fsck_apfs -y on the disk in Rescue Mode mode does produce a number of warnings on one of the filesystem snapshots of the following type:

warning: Cross Check : Mismatch between extentref entry reference count (1) and calculated fsroot entry reference count (0) for extent (0x236654a + 4)


This does not seem to be repaired by fsck_apfs though.

Any clues as to how to go about deleting this directory?



For those who wonder, the directory was initially found as a subdirectory of a Steam game (Factorio, release 0.17.0).  The original path of the directory was ~/Library/Application Support/Steam/steamapps/common/Factorio/factorio.app/Contents/data/base/campaigns/demo/locale/ru.  The part from demo downwards caused the game to not start properly (it was, apart from the directories, empty, but the game tried to pick up some non-existing file from the demo directory and crashed). Moving the directory away made the game playable, but I later discovered that the bottom-most ru directory could not be deleted.  This is the directory that I then renamed strange and that I refer to throughout this question.

I have submitted feedback to Apple about this, but I'm no Apple developer so I can't submit a formal bug report.
I filed a bug report with Apple and this seems to finally be fixed now in Mojave 10.14.4 (18E226).

To fix, update your OS to the latest version. Then reboot into recovery (CMD-R) and run disk first aid. 

It should show one or more error: directory valence check: directory (oid 0x123456): nchildren (1) does not match drec count (0)  and / or error: nchildren of inode object (id 12345678) does not match expected value and repair them.

Once it is done, reboot into OS X and you should finally be able to delete the folder normally!