Cannot delete/rename/move a file from Windows with a special character

I have just recently found this issue too in El Capitan 10.11.3. Exact same problem. Denied error, have tried everything except reinstall but this feels like an OS X issue that could be solved in a future release by Apple.

Funny, or maybe not so funny, is that it is totally ok to copy the file, but not deleting it ;-)

@Apple - please help out here, seems like a silly but very annoying bug

On UNIX™ systems, the worst thing that you can do is embedd a null string into a filename, as all of the user commands, and system calls to manipulate that file will fail when they encounter that unexpected null string. This has nothing to do with your Desktop folder permissions/ACL which mirror my settings in OS X 10.11.3.

I created one of these null embedded filenames as a test. Nothing will copy/rename/remove it:

1. All variations of the rm command including Hiroto's cognitive collection on El Capitan
2. All variations of [1] with folder containing the file mounted on OS X Snow Leopard
3. All variations of [1, 2] using unlink command in the Terminal
4. Removal of inode for offending filename, including the Find sequences.
5. Package manager (homebrew) installed GNU Coreutils with that grm command
6. C++ program employing unlink() system call
7. Python/Objective-C using NSFileManager.removeItemAtPath, and another using os.remove(old, new)
8. Perl implementation of unlink (essentially rm -i written in Perl)
9. vim ./
10. emacs ./

Bottomline: There is no interactive means to remove a null embedded filename on a UNIX™ system, short of a clean install, and restoring all personal files but that null embedded one.

Hello

As far as I have tested, I can delete file with null-embedded filename under OS X 10.6.8. So I suggested mounting the volume with file in question to OS X 10.6.8 machine by means of target disk mode and trying to delete it from there.

H

Hiroto,

Yes, I did that as item 2 of my last post. Although one or more of your quoted filename suggestions returned without error (even on El Capitan), the file remains undeleted. Removing this file has no priority now, and eventually, it will be assimilated by a clean install. 😉

Hello VikingOSX,

Mounting the folder containing the file to OS X Snow Leopard implied to me some file sharing, remote access via ssh etc, which is obviously different from target disk mode. The point is I think OS X 10.6.8 has direct access to the HFS Plus file system where the file in question resides whereas remote access from OS X 10.6.8 only asks host OS to access its file system.

H

My bad. Reading your target disk mode suggestion, but implementing sharing solution. Duh.

Let me see if I have the toys and connectivity here to do TDM. Will let you know.

As Hiroto succintly pointed out, he was recommending a target disk mode (TDM) solution where Snow Leopard would act directly on the filesystem containing the filename with null in it. I did a file sharing solution to Snow Leopard, but not TDM. Looking to see if I can do TDM here with my equipment, and evaluate if Snow Leopard sees this removal problem differently than later OS X implementations.

Hold off on any OS X reinstall for now.

The 2009 mini was repurposed with Yosemite, and did not retain the Snow Leopard partition. Aside from the fact that I do not have the time now to repartition and install an additional Snow Leopard partition on that older mini, I also lack a length of FW800 cable for TDM.

Providing you do not have any other alias files on your Desktop, rather than beat on this any longer, just hide the darn thing. In Terminal:

$ cd ~/Desktop

$ chflags hidden *alias

Simple. No need to do anything else.

HI, I'm following this thread with interests.

Here is the result of my tests.

Test-1: Other version of OS X

1. Create a writable disk image (DMG) containing a test file with the special character in its name.
2. Copy the DMG on to the target mac.
3. On the target mac, mount the DMG and try to delete the test file.

The file is successfully deleted with rm command in Terminal on 10.7.5, 10.10.5, but failed on 10.11.3.

Note:

• I used a normal empty file created with touch command, not an alias to make test simple.
• The disk image was successfully unmounted ( ejected ) even on 10.11.3

Test-2: unlink system call

I wrote a simple program to delete files using unlink system call. The result is the same, Invalid argument.

Test-3: rename system call

The same result as Test-2.

( rename is just a combination of link and unlink in basic, in my understandings )

I guess, it is most likely due to the problem on handling HFS+ file system on El Capitan.

If so, re-installing EC won't solve.

If this happen on my mac, I will try

1. Create a bootable USB stick with Yosemite.
2. Boot from the USB stick.
3. Open Terminal app and use rm to delete the file.

I haven't tested this yet. - report the result later.

Hopefully, someone will take the time to report this as a bug to apple. You should not be allowed to create files that you cannot delete.

R

Just an update.

1. Create a bootable USB stick with Yosemite.
2. Boot from the USB stick.
3. Open Terminal app and use rm to delete the file.

This worked on my Macbook Pro running 10.11.3.

Older version of OS X may be used instead of Yosemite.

I can confirm that the following sequence worked by booting from a Yosemite USB stick, and using Terminal from Utilities. Another strong reason to have a bootable USB stick with a previous OS X release on it. My file was not in a DMG. What a PITA.

$ rm -f "Xiumi's Backup"$'\342\220\200'" Alias"