How to kill a zombie System folder?

[jpdemers]

I have an external HD ("850 GB EXT") that was, at one time, the boot volume for an older iMac. I put it in a case and converted it to an external backup for my present system (mid-2007 iMac running El Capitan). Being a bit lazy, I left all the old files in place, in case I might want them for anything.

That was a few years ago, and by now I've rooted around and copied out everything worth saving. Time to clean up and make room, so I started deleting the folders (Users, Applications, etc.) By one means or another, including forced deletions (sudo rm), I've gotten it down to a single System folder and four nested folders within: System>Library>Caches>com.apple.kext.caches>Startup. The folders are empty, and add up to zero bytes.

This is where it gets weird. I can trash any of the internal folders, and empty the trash, but when I try to delete the System folder, it re-appears in the HD directory within a few seconds . . . with the four nested files resurrected as well. There's an image in the Trash, which can be emptied as if nothing was wrong. Console has some interesting output - the following appears consistently when I drag the System folder to the trash:

06/22/2016 3:58:21.132 PM com.apple.kextd[55]: Warning: /Volumes/850 GB EXT/System/Library/Extensions: No such file or directory
06/22/2016 3:58:21.132 PM com.apple.kextd[55]: Warning: /Volumes/850 GB EXT/Library/Extensions: No such file or directory
06/22/2016 3:58:21.235 PM com.apple.kextcache[1089]: Warning: /Volumes/850 GB EXT/System/Library/Extensions: No such file or directory
06/22/2016 3:58:21.235 PM com.apple.kextcache[1089]: Warning: /Volumes/850 GB EXT/Library/Extensions: No such file or directory
06/22/2016 3:58:21.235 PM com.apple.kextcache[1089]: rebuilding /Volumes/850 GB EXT/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache
06/22/2016 3:58:21.247 PM com.apple.kextcache[1092]: No kernel extensions found.
06/22/2016 3:58:21.248 PM com.apple.kextcache[1089]: Child process /usr/sbin/kextcache[1092] exited with status 70.
06/22/2016 3:58:21.248 PM com.apple.kextcache[1089]: Error 107 rebuilding /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache
06/22/2016 3:58:21.248 PM com.apple.kextd[55]: helper error while updating /Volumes/850 GB EXT (error count: 12)
06/22/2016 3:58:21.336 PM com.apple.kextd[55]: async child pid 1089 exited with status 70

It's odd that the Finder can locate these, while deeper system processes can't. They take up zero bytes, but I think it's bogging down some processes - the Mac is noticeably quicker when the drive is not mounted.

Re-formatting would be a pain - I'd have to relocate about 450 GB of images and video to DVDs, or buy yet another external drive. Anybody have any ideas about how to kill a zombie folder?

 

[simonsi]

They are a cache so the system will recreate them as it needs, that is why the system runs slower when the drive is mounted, the system is using those folders - why is another question that I can't answer and it maybe a symptom of a wider issue if the system thinks some active system folders are on the drive...

 

[jpdemers]

They are a cache so the system will recreate them as it needs, that is why the system runs slower when the drive is mounted, the system is using those folders - why is another question that I can't answer and it maybe a symptom of a wider issue if the system thinks some active system folders are on the drive...

If I log in as a new user, it's exactly the same behavior.
If I start in safe mode, I can delete it and it stays deleted . . . until I re-start in normal mode.
So yeah, the OS seems to think there should be a kernelcache in there, and wants to rebuild it... the question is WHY?

 

[richard2]

Please do the following:

1. Open Terminal.
2. Type the following:
   
   bless --info /; bless --info
3. Type a space.
4. Drop the problematic volume onto the window.
5. Focus (bring to the foreground) the Terminal window and then press return.
6. Include the contents of the Terminal window in a reply to this post.