Can't delete some fake files

You must have inadvertently clicked on the Solved button for that response since only the person who starts a topic can award Solved and Helpful marks.

Sorry, there's no way to undo it. Not even the hosts can change it. Don't worry about it, though. It happens a lot.

I copied the file name you have in your initial post (without the leading period) so I could play with it. I created a folder on the desktop, put a small TextEdit, plain text file in the folder and renamed it with that oddball name.

That was it. Once there, it's stuck like glue. You can't rename it via the desktop. You can't rename or get rid of it with any commands in Terminal. I'm not sure if you can even move the folder and/or the file around to other areas of the drive. I didn't try that.

The file name is so stuck that way, I gave up and used the registered version of SuperDuper! to restore the backup of the test volume I was on. When it got to that file/folder to remove it (to match the source it was restoring from), it did this:

SD! croaked and halted. The only way to get rid of it was to erase the volume and then restore the entire backup.

These nul ( poo emoji ) byte filenames are cockroach resilient. Only booting into an older OS X release (e.g. Mountain Lion worked for me) will allow one to remove them with standard CL tools. Otherwise, it is slash and burn, which may not be worth it.

That's a different issue. Strangely named files cannot in any way prevent you from booting to another volume.

Restart and immediately hold down the Command+Option+R+P keys. Keep holding them through two or three startup chimes and release the keys as it's going around for another startup. Switch over to just the Option key. You should get the Startup Manager so you can select another volume to boot to.

i'm unsure what these files are myself i didn't follow all this 3rd party application havoc - i didn't readit

open terminal give unlink(1) a try (useful for deleting files

$ rm file # failed, filename strange

# ok didn't work

$ man unlink # try it

$ unlink file~~~

# might work

BUT FIRST look a the permissions on the files and directory. make sure you have permission to change these files first. you maybe need to be "admin" or even "root" to change permissions so that you can then remove them. use Finder if you did change permissions it should now work

find(1) has a -print0 feature for dealibg with strange names, but you would rather: invoke a pro to help you

allow a pro access to login to your (soon to be pancaked mac) to delete the files for you, or as other's suggested restore manufacturer "El Capitan" verbatim and copy over user files from backup (ughgh). you'd have to re-install all apps (but if your re-installing, that can be better than attempting to restore 3rd party apps via backup).

if being "root" is not enough permission to remove the files then somehow a 3rd party access the upper tier of permission reserved for apple corporation to protect you: and you should contact apple that an application they "signed" has breached "contract" with them and done this

(that assumes you, with pro's advice, have actually determined file permission is the issue)

and yes - you may see funny file names (??????) in Unix given permissions that allow you to see in a directory but see files in the directory your not allowed to see/read. really depends there no confirmation that being true in apple unix or Finder.

In my test, I created the folder, and copied in a very simple text file. Both of which I was the creator and owner of, so I had all the permissions in the world to copy, delete or anything else to these items. As soon as renamed the file, I couldn't do a thing with it. So it has something to do with the name, not permissions. The OS is not handling something in the name correctly.

Edit: Just did a little more digging. There are certain characters that shouldn't be used in a file or folder name in Unix. Many of which the Mac OS has no trouble with you using anyway. But the big one here (according to a couple of sites on the subject) is the NUL character. As far as Unix is concerned, NUL represents the end of the file name. Once you put one in there, it becomes virtually impossible to rename or delete the file since Unix can't match the name to a file table entry. It sees:

.OUunh!␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀␀.AcVG6n

as

.OUunh!

So it balks at any attempt to anything with the file since there is no item by that name in the file table. But as VikingOSX noted, if you boot into an old enough version of OS X, you can remove or rename them without issue. So it seems to be more of an introduced bug than anything else.

There is a superuser level:

1. How to Enable the Root User Account in Mac OS X.
2. Using "sudo" is usually sufficient.
3. Booting into Single-user Mode.

The command 'cal 9 1752' works fine in OS X 10.11.6:

cdhw$ cal 9 1752

September 1752

Su Mo Tu We Th Fr Sa

1 2 14 15 16

17 18 19 20 21 22 23

24 25 26 27 28 29 30

The 'missing days' are not a bug they are due to Britain changing to the Gregorian calendar.

C.