Can't delete file or empty trash with file in it ...

[tomllama]

I have a number of files that got copied to and HFS+ disk on my Mac somewhere along the line. They came from Windows 10.
The files can't be deleted normally from the trash. I can move them out of the trash and then try using terminal to either delete them using rm -rf (which fails). I've tried to rename them too make them 'normal' but that fails too.

For example:
mv "._20090801-2555903 (2018_04_11 18_36_40 UTC).ldx" "20090801-2555903 (2018_04_11 18_36_40 UTC).ldx"

does not work. Using sudo to rename or delete does not work. All I get is an 'operation not permitted' error. The files do not show up in finder, even when I have hidden files turned on. The files don't show in terminal with just 'ls', then only show with 'ls -a'

Disk repair does nothing, file structures are fine. OSX simply refuses to let me delete them (given my poor skill level). How do I delete them?

 

[Gregg2]

Worth a try: put them in a common folder, delete the folder
???

 

[tomllama]

Na, that doesn't work either. I can move them around via terminal commands (no via finder), but no go on the deletion.

 

[chown33]

Use the ls options -leaO on the files. Post the output using CODE tags.

If you have problems with the command, then copy and paste the command from the Terminal window and post it here.

It's normal for the files to not show up without the -a option, since their names start with dot. Such names are normally suppressed in ls output, otherwise you'd see the directories "." and ".." everywhere.

To illustrate, paste this command into a Terminal window:

ls -la ~

There should be "." and ".." entries, a ".Trash" directory, maybe some ".profile" files, likely a ".DS_Store" file, and an unpredictable number of other files and folders whose names start with dot.

 

[tomllama]

This is what I get for the directory that includes the files it will not let me delete:

Toms-MBPro:GGR tom$ ls -leaO
total 48
drwxr-xrwx 5 tom staff - 170 Jun 18 10:21 .
drwxr-xrwx 4 tom staff - 136 Sep 28 14:38 ..
-rwxr-xr-x@ 1 tom staff uchg 4096 Mar 27 2010 ._20090801-2555903 (2018_04_11 18_36_40 UTC).ldx
-rwxr-xr-x@ 1 tom staff uchg 4096 Mar 27 2010 ._20090801-2555904 (2018_04_11 18_36_40 UTC).ldx
-rwxr-xr-x@ 1 tom staff uchg 4096 Mar 27 2010 ._20090802-2555900 (2018_04_11 18_36_40 UTC).ldx

To answer the obvious, I have admin privileges (and I've tried the delete using sudo too).

 

[chown33]

You own the files and the directory they're in, so ownership isn't the cause.

The files are shown as locked (the uchg flag). They also have extended attributes (the @ symbol). Please post the output of this command:

ls -leaO@

Also post the output of:

pwd ; mount

Please post output with CODE tags, not QUOTE tags.


Try this to turn off the uchg flag on one of the files:

chflags nouchg ._20090801-2555904*

I recommend that you copy and paste that into a Terminal window, to avoid accidentally mistyping it.

If that cmd gets an error, then post the complete command-line and its output in CODE tags.

If it succeeds (i.e. no error message), then an ls -leaO@ should show exactly one file now lacking the uchg flag, while the others still have it. If that's the case, then try rm'ing that file, which shouldn't need 'sudo'.

 

[tomllama]

Toms-MBPro:GGR tom$ ls -leaO@
total 48
drwxr-xrwx  5 tom  staff  -     170 Jun 18 10:21 .
drwxr-xrwx  4 tom  staff  -     136 Sep 28 14:38 ..
-rwxr-xr-x@ 1 tom  staff  uchg 4096 Mar 27  2010 ._20090801-2555903 (2018_04_11 18_36_40 UTC).ldx
    com.apple.FinderInfo      32 
-rwxr-xr-x@ 1 tom  staff  uchg 4096 Mar 27  2010 ._20090801-2555904 (2018_04_11 18_36_40 UTC).ldx
    com.apple.FinderInfo      32 
-rwxr-xr-x@ 1 tom  staff  uchg 4096 Mar 27  2010 ._20090802-2555900 (2018_04_11 18_36_40 UTC).ldx
    com.apple.FinderInfo      32

Toms-MBPro:GGR tom$ pwd ; mount
/Volumes/Outrigger/FileHistory/GGR
/dev/disk1s1 on / (apfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk1s4 on /private/var/vm (apfs, local, noexec, journaled, noatime, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk0s3 on /Volumes/BOOTCAMP (tuxera_ntfs, local, synchronous)
/dev/disk2s2 on /Volumes/TrackRat4 (tuxera_ntfs, local, nodev, nosuid, synchronous)
/dev/disk5s2 on /Volumes/Outrigger (hfs, local, nodev, nosuid, journaled, noowners)
/dev/disk4s1 on /Volumes/Clone (apfs, local, nodev, nosuid, journaled, noowners)
/dev/disk5s3 on /Volumes/WinClone (tuxera_ntfs, local, nodev, nosuid, synchronous)
//tom@MiniServer._smb._tcp.local./TimeMachine on /Volumes/TimeMachine (smbfs, nobrowse)
/dev/disk6s2 on /Volumes/Time Machine Backups (hfs, local, nodev, nosuid, journaled, nobrowse)

Ha, the chflag worked ..

Toms-MBPro:GGR tom$ chflags nouchg ._20090801-2555904*
Toms-MBPro:GGR tom$ ls -leaO
total 48
drwxr-xrwx  5 tom  staff  -     170 Jun 18 10:21 .
drwxr-xrwx  4 tom  staff  -     136 Sep 28 14:38 ..
-rwxr-xr-x@ 1 tom  staff  uchg 4096 Mar 27  2010 ._20090801-2555903 (2018_04_11 18_36_40 UTC).ldx
-rwxr-xr-x@ 1 tom  staff  -    4096 Mar 27  2010 ._20090801-2555904 (2018_04_11 18_36_40 UTC).ldx
-rwxr-xr-x@ 1 tom  staff  uchg 4096 Mar 27  2010 ._20090802-2555900 (2018_04_11 18_36_40 UTC).ldx

Once I saw that, I changed all the flags and then deleted using a simple rm ._*
Thanks. Learned something new. Your help is greatly appreciated.

 

[chown33]

Glad it worked.

Now I'll explain why I asked for pwd ; mount output.

First, here are the relevant parts of the data you posted:

/Volumes/Outrigger/FileHistory/GGR

/dev/disk5s2 on /Volumes/Outrigger (hfs, local, nodev, nosuid, journaled, noowners)

The first line, which is output from pwd, tells me the directory GGR, where the files are located, is on an external volume Outrigger. I suspected this might be the case after you posted the ls output which showed you owned the files. The reason I suspected that shows up in the info from mount.

The second line is the output from mount. This tells me several things:
1. The file-system format is HFS (hfs).
2. It's Journaled HFS+ (journaled).
3. Ownership is ignored (noowners).

When ownership is ignored, the system instead gives ownership to whoever is logged in when the disk is mounted (SD card or USB plug inserted, network share attached, etc.). That is, if the original owner was someone else, then that ownership is overridden. This is a good thing in this case, because it means 'sudo' won't be needed.

The only odd thing in all of this is why there would be any ._ files in the first place.

Those files are only created when Mac files are copied to a file-system that doesn't support extended attributes. Since the volume is HFS+, which does support extended attributes, there's no obvious reason why the files should exist. It's most likely from some earlier file copying that originated from a volume that doesn't support extended attributes, so the ._ files were mistakenly copied instead of being converted into extended attributes as they normally would be. File-systems like FAT32 or ExFAT don't support extended attributes, so it's possible that a volume in that format was part of the chain of file copying somewhere along the way.

The other thing that's likely to have happened is that the original files were locked (Finder > Get Info > Locked checkbox), which resulted in the ._ files being locked (the uchg flag). Another possibility is that the ._ files somehow were locked while a FAT32 or ExFAT volume was being used on Windows. That's just a wild guess.

 

[tomllama]

Thanks for the explanation.

The files originated in Win 10 (bootcamp) and an NTFS disk (a different disk than it's on now, and it could have gone through an intermediate too). It is highly likely that something got scrozzeled recently as I was reworking my backup strategy and I noticed that a disk that should have been NTFS had been converted to HFS.