35

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

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.

Improve this question
31
  • 2
    could it be an open deleted file?
    – Rui F Ribeiro
    Commented Feb 26, 2019 at 22:37
  • 2
    yeah, ls -la should normally show a .DS_Store
    – Rui F Ribeiro
    Commented Feb 26, 2019 at 22:48
  • 3
    Seriously file a bug report, Apple will give you test builds to sort it out.
    – user1133275
    Commented Feb 26, 2019 at 23:21
  • 3
    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
    Commented Feb 27, 2019 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
    Commented Feb 27, 2019 at 13:53

3 Answers 3

Reset to default
21
+50

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!

Improve this answer
1
  • 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
    Commented Mar 27, 2019 at 17:12
1

In a nutshell:
1) update OSX to the latest version
2) start in recovery mode
3) start disk first aid (which should fix stuff)
4) restart

Improve this answer
3
  • The existing accepted & bountied answer already says this.
    – Tetsujin
    Commented Mar 18, 2020 at 15:47
  • 2
    @Tetsujin I totally agree with you. But since yesterday I had the same problem, I could not understand the solution using only the accepted answer and therefore I had to cross-reference multiple answers. So I said to myself "Why not rewrite the answer in a more schematic way so that if he were to ask himself the problem again in the future, I know exactly what to do?" I believe that stack exchange responses also have the purpose of being used as very useful documentation to the problems we have faced, not just once...
    – Memmo
    Commented Mar 19, 2020 at 8:30
  • ... @Tetsujin, so save them to be able to quickly consult them again in the future, I think it's the right thing to do.
    – Memmo
    Commented Mar 19, 2020 at 8:30
0

Adam's answer is correct and my previous answer itself not that helpful, but I include this from the comments section as another thing to try:

Try deleting your APFS snapshots:

  • tmutil listlocalsnapshots
  • sudo tmutil deletelocalsnapshots SNAPSHOT_DATE
Improve this answer
4
  • 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
    Commented Mar 17, 2019 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 ♦
    Commented Mar 17, 2019 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
    Commented Mar 17, 2019 at 20:24
  • @OldPro Still have to do some further check but I had the same issue as above (even worst as my disk was actually full) and I fixed it with tmutil listlocalsnapshots / and sudo tmutil deletelocalsnapshots SNAPSHOT_DATE. Thank you! You saved my day.
    – Alessandro Benoit
    Commented Sep 6, 2019 at 15:22

You must log in to answer this question.

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