Undetectable file?

Running up to date Sonoma on a Studio and Disk Utility shows no errors.

I’ve got a file that’s actually a package (a Lightroom .lrdata file) that contains 2 folders each of which contains 3 folders but all are empty. File shows as zero bytes but cannot be deleted. I’ve checked for lock and permissions on both the package and all the subfolders. Tried safe mode. Tried a chmod -N as I found on Reddit. Tried right click and delete immediately inside the trash. Nothing works but the last one gives me an error that says to check for lock and permissions in Get Info. Tried the lsof | grep technique…the file shows not in use. Booted into recovery, Disk Utility says boot drive is fine, launched Terminal went to /Volumes/bootdrive/Users/adminuser/.Trash (which is where the file is found in terminal when logged in as the normal admin user) and the file is not in the .Trash folder. Rebooted, logged in as a different admin user, the file in question is not in Trash on the desktop.

Of note…when emptying the trash on this machine the progress bar never disappears about half the time…but if I click stop emptying trash and then look in the trash it’s actually already empty. Not sure what that has to do with anything.

Googled and tried everything on the various pages I could find…all of that in the above.

Any additional ideas/suggestions?

You did use ‘sudo’ while in terminal trying to zap the package? Did you try ‘sudo rm -r lightroom.lrdata’ assuming that’s the file’s name? No file should be able to resist yielding to that command. Otherwise it sounds like the file (package) is not actually there yet still listed in the filesystem. I’d then come up with ‘fsck’ in the terminal.

Are you sure it’s actually in /Volumes/bootdrive/Users/adminuser/.Trash? Although that is the most common place, the Finder’s Trash folder is actually a composite of several trash locations, including per-volume trash folders (for things not on the boot volume) and I think also per-container trash folders (for apps running in containers).

If you do a Get Info on the file from the Finder’s trash folder, check the “Where” line to see its actual location:

Screenshot 2024-01-15 at 19.11.21

Your file may be in an unexpected location, but the Finder’s Info page should tell you where it really is.

I agree with @Shamino but recommend dragging the file from trash to a terminal window as it will get you the path to do

sudo rm -rf

1 Like

No file should be able to resist yielding to that command. No file should be able to resist yielding to that command.

No file “should be able to resist” but Apple thinks different. No file covered by SIP can be deleted even by “sudo rm” unless SIP is disabled. I have been surprised what SIP covers.

OK, replying to all suggestions here.

Yep…tried sudo and also su root since root is enabled on my machines.

And yes, the file is actually in .Trashes/.Trash on my external RAID (thanks for the tip about checking in Get Info which I should have known to try)…which means I can’t get to it in Recovery mode since the SoftRAID drivers aren’t there. I was able to move it back to the RAID for more attempts with it not in the trash.

Doing an ls -la on the RAID I get the following

drwxrwxrwx@ 4 susanh wheel 136 Jan 15 11:41 Laubenthal_Master-v12 Previews.lrdata

Get Info shows the file is not locked and everybody has R/W access and Get Info on the total of 8 nested subfolders also shows nothing locked and everyone with R/W.

This
sudo rm -rf /Volumes/ThunderBay\ mini/Laubenthal_Master-v12\ Previews.lrdata

Gives me this
rm: /Volumes/ThunderBay mini/Laubenthal_Master-v12 Previews.lrdata/0/06FA: Permission denied
rm: /Volumes/ThunderBay mini/Laubenthal_Master-v12 Previews.lrdata/0/0AA1: Permission denied
rm: /Volumes/ThunderBay mini/Laubenthal_Master-v12 Previews.lrdata/0/0B78: Permission denied
rm: /Volumes/ThunderBay mini/Laubenthal_Master-v12 Previews.lrdata/0/0CB3: Permission denied
rm: /Volumes/ThunderBay mini/Laubenthal_Master-v12 Previews.lrdata/0/0CDF: Permission denied
rm: /Volumes/ThunderBay mini/Laubenthal_Master-v12 Previews.lrdata/0: Permission denied
rm: /Volumes/ThunderBay mini/Laubenthal_Master-v12 Previews.lrdata/7/71EE: Permission denied
rm: /Volumes/ThunderBay mini/Laubenthal_Master-v12 Previews.lrdata/7: Permission denied
rm: /Volumes/ThunderBay mini/Laubenthal_Master-v12 Previews.lrdata: Permission denied

Since the offending file is a package…cd into that directory and sudo ls -la gives me
drwxrwxrwx@ 4 susanh wheel 136 Jan 15 11:41 .
drwxrwxr-x+ 26 susanh admin 952 Jan 16 15:10 …
drwxrwxrwx 7 susanh wheel 238 Jan 15 11:39 0
drwxrwxrwx 2601 susanh wheel 88434 Jan 15 11:40 7

Where 0 and 7 are the two subdirectories inside the package.

cd 0 and ls -la gives me
xxx@xxx 0 % ls -la
total 0
drwxrwxrwx 7 susanh wheel 238 Jan 15 11:39 .
drwxrwxrwx@ 4 susanh wheel 136 Jan 15 11:41 …
drwxrwxrwx 7 susanh wheel 238 Jul 2 2022 06FA
drwxrwxrwx 3 susanh wheel 102 Feb 17 2022 0AA1
drwxrwxrwx 4 susanh wheel 136 Nov 27 2022 0B78
drwxrwxrwx 6 susanh wheel 204 Feb 27 2021 0CB3
drwxrwxrwx 3 susanh wheel 102 Jan 4 2021 0CDF

With similar results when I cd into the 7 subdirectory.

I also tried with su root all of the above with no changes.

If anybody has more suggestions for getting rid of this I’ll try them…but for now I think I’ll just put it into a WontTrash directory on the RAID and not worry about it. It’s really weird and it’s a zero byte file, perhaps the ls outputs above will provide little more

I noticed something interesting…

Can you also run:

ls -alde@ /Volumes/ThunderBay\ mini/Laubenthal_Master-v12\ Previews.lrdat

I thought I saw an @ sign on the permissions for that bundle. If so, there may be some other attributes or ACLs in play here.

2 Likes

Also include -O (that’s a capital oh) on the ls. That prints the flags. Those files may have the schg (or uchg, although I think that shouldn’t affect removing them as root) flag set on them. Alternatively, just do a:

sudo chflags -R noschg,nouchg /Volumes/ThunderBay\ mini/Laubenthal_Master-v12\ Previews.lrdata

to turn off those flags, then try the rm -rf again.

1 Like

Sorry to be late getting back to this…but today was the first time I was back at that computer since I received these suggestions.

ls -alde$ as suggested by Technogeezer gives me

drwxrwxrwx@ 4 susanh wheel 136 Jan 15 11:41 /Volumes/ThunderBay mini/zCannotTrash/Laubenthal_Master-v12 Previews.lrdata
com.apple.lastuseddate#PS 16
com.apple.macl 72

And sudo chflags -R noschg,nouchg and than an ls -laO
As suggested by blm

Gives me

drwxrwxrwx@ 4 susanh wheel - 136 Jan 15 11:41 Laubenthal_Master-v12 Previews.lrdata

So the permissions aren’t getting removed from the file so then rm -rf gives me

rm: /Volumes/ThunderBay mini/zCannotTrash/Laubenthal_Master-v12 Previews.lrdata/0/06FA: Permission denied
rm: /Volumes/ThunderBay mini/zCannotTrash/Laubenthal_Master-v12 Previews.lrdata/0/0AA1: Permission denied
rm: /Volumes/ThunderBay mini/zCannotTrash/Laubenthal_Master-v12 Previews.lrdata/0/0B78: Permission denied
rm: /Volumes/ThunderBay mini/zCannotTrash/Laubenthal_Master-v12 Previews.lrdata/0/0CB3: Permission denied
rm: /Volumes/ThunderBay mini/zCannotTrash/Laubenthal_Master-v12 Previews.lrdata/0/0CDF: Permission denied
rm: /Volumes/ThunderBay mini/zCannotTrash/Laubenthal_Master-v12 Previews.lrdata/0: Permission denied
rm: /Volumes/ThunderBay mini/zCannotTrash/Laubenthal_Master-v12 Previews.lrdata/7/71EE: Permission denied
rm: /Volumes/ThunderBay mini/zCannotTrash/Laubenthal_Master-v12 Previews.lrdata/7: Permission denied
rm: /Volumes/ThunderBay mini/zCannotTrash/Laubenthal_Master-v12 Previews.lrdata: Permission denied

Where those are all the empty subfolders in the package…and all of which (as well as the package itself) show zero bytes in Info window.

And just for grins…I also tried su root since it is enabled and repeated all of the above with the same results

I used to do unix a bit when I was a working buy…and I never knew that there was such a thing as permission denied to root…but maybe root in macOS ain’t the same as the root we all know and love.

More ideas anyone…or is this just a problem destined never to be solved. I’ve worked around it a bit by putting it back into the zCannotTrash folder at the root of the RAID…but that’s a pretty unsatisfying solution.

Any flags would show up after the group, so in the case above it’s the - after wheel, which means no flags. So the chflags either did it’s work or there weren’t any flags there to start with.

One additional thing to try:

ls -ldO /Volumes/ThunderBay mini/zCannotTrash/Laubenthal_Master-v12 Previews.lrdata/0/06FA

If that shows a - (or something other than sunlnk) after the group, then I’m baffled. If it shows sunlnk (a flag undocumented in man chflags, thank you Apple :man_facepalming:), then that directory (and presumably the others) can’t be removed with SIP on, so you’d have to turn it off, remove everything, then turn SIP back on.

Hmmm, that’s probably wrong :face_with_open_eyes_and_hand_over_mouth: I did a test where I created a disk image, created a file called test on the disk image’s volume, did a chflags sunlnk test, and it deleted just fine. Maybe it’s only files with the sunlnk flag on the booted volume that can’t be removed with SIP on?

Anyways, the ls I suggested is still probably worth doing, and if sunlnk is on for the directory, maybe try turning off SIP to remove it, but I don’t think that’s the problem now, which means I have no idea what it is.

I agree that fsck or Disk First Aid are worth running.

Hmmm. I wonder if the com.apple.macl attribute shown here is the reason this can’t be deleted.

The attribute doesn’t seem to be documented. I did find:

In that first reference:

Jeff Johnson

[…]
The com.apple.macl extended attribute is so persistent that you can’t even delete it.

Michael Tsai

Unless you turn off System Integrity Protection. […]

So… perhaps the com.apple.macl attribute can be deleted by turning off SIP, then using xattr -d com.apple.macl Laubenthal_Master-v12 Previews.lrdata. Perhaps with sudo. And also remove the attribute the same way on any files / folders within that .lrdata folder.

I’m not sure if that would then allow the file to be deleted. Worth a try though?

I’ve just been able to remove the com.apple.macl attribute on an ISO file that I found that had it set - on a Mac that does not have SIP disabled (in Sonoma 14.3):

sudo xattr -d com.apple.macl filename.iso

perhaps this needs to be done recursively with nested directories, starting at the top level folder that has the attribute set?