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/
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*
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 ..

enter image description here

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.

migrated from unix.stackexchange.com Feb 27 at 13:11

This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.

  • 1
    could it be an open deleted file? – Rui F Ribeiro Feb 26 at 22:37
  • 2
    yeah, ls -la should normally show a .DS_Store – Rui F Ribeiro Feb 26 at 22:48
  • 2
    Seriously file a bug report, Apple will give you test builds to sort it out. – user1133275 Feb 26 at 23:21
  • 2
    I concur with @user1133275: APFS is a relatively new filesystem, and so somewhat more likely to contain new bugs. You may have hit a corner case that is not covered by the Disk Utility's First Aid. Examples of real-life error situations (in the form of bug reports) help in improving the Disk Utility and making the new filesystem more stable. Also, try sudo lsof +L1 to explicitly list any deleted-but-still-open files system-wide: a basic lsof targeted to a specific directory will only report on files that are there, and a deleted file does not quite qualify. – telcoM Feb 27 at 9:37
  • 2
    I'm guessing that the file is named the null character. I would file a bug report with Apple but that doesn't mean that Apple will contact you with an answer/fix. – fd0 Feb 27 at 13:53

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!

  • Ah, yes. I updated the machine just recently but didn't get back to this issue. Thanks! Running a disk repair in recovery mode does seem to solve it now and I was finally able to delete that pesky directory. Much thanks! – Kusalananda Mar 27 at 17:12

Unfortunately, find is not your friend in this search, as it suppresses . and .. and so could be suppressing your mystery file:

user$ find . -links 3 -name '.*' -ls
user$ ls bar
user$ ls -iad bar
10541088 bar/
user$ ls -iad bar/.
10541088 bar/./
user$ ls -iad bar/l1/..
10541088 bar/l1/../
user$ find . -inum 10541088 -ls
10541088        0 drwxr-xr-x    3 user             admin                 102 Mar 17 11:36 ./bar

Note that although bar, bar/., and bar/l1/.. all are hard links to the same inode, find only lists one of them.

Although it is a bit painful, I suggest you search again using ls, as in

sudo ls -aiR / | grep 786499

where "786499" is the inode number of the strange directory.

  • Thanks for your effort, but I still only find two entries anywhere under / with that inode number. The strange directory entry itself and the . entry inside it. – Kusalananda Mar 17 at 19:56
  • The three names you mentioned are not three hardlinks to the same file, so it is kind of obvious that your find command doesn’t find the inode they represent. And they represent directories anyway, which usually can‘t be hardlinked. – nohillside Mar 17 at 20:16
  • 1
    @Kusalananda that is not entirely unexpected, but I thought it worth a try. Next thing I would try is deleting your APFS snapshots: tmutil listlocalsnapshots / and sudo tmutil deletelocalsnapshots. @nohillside if you look at the output of ls you will see that the 3 names all refer to the same inode. – Old Pro Mar 17 at 20:24

You must log in to answer this question.

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