bidiu

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

Not long ago, I used a portable hard drive to switch some data between my PC and MacBook (Running OS X 10.11.1).

Unfortunately, I was stupid to make an alias for my hard drive on my Mac's desktop by accident, right after my portable hard drive was mounted.

The question is that I can't even delete/rename/move it. Restarting system doesn't work, and commands (sudo rm/mv ..) from the Terminal doesn't work either.

 

When I was trying to remove/move the alias file, I got what's like this, "The operation can’t be completed because an unexpected error occurred (error code -50)."

And when trying to rename it with filename "a", I got what's like this, "Try using a name with fewer characters, or with no punctuation marks.''

 

I think this probably has to do with the hard drive's name, which has a weird character "NUL", one character. Maybe this character is legal in Windows, but illegal in OS X? Or maybe there're some differences between Windows and Mac interpreting a filename?

 

Any help, thanks!

MacBook Pro with Retina display, OS X El Capitan (10.11.1)

Posted on Jan 5, 2016 11:19 PM

Close

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

  • All replies
  • Helpful answers

Previous Page 2 of 3 last Next
  • by bidiu,

    bidiu bidiu Jan 12, 2016 9:27 PM in response to Alberto Ravasio
    Level 1 (1 points)
    Jan 12, 2016 9:27 PM in response to Alberto Ravasio

    Hello, thanks for your help.

     

    Here is the output:

    Screen Shot 2016-01-13 at 12.55.08.png

    I have the permission of r/w/x in the ~/Desktop folder. And I think, not 100% sure, this problem has to do with illegal characters in the filename.

  • by AndreasBSweden,

    AndreasBSweden AndreasBSweden Feb 10, 2016 9:03 AM in response to bidiu
    Level 1 (4 points)
    Feb 10, 2016 9:03 AM in response to bidiu

    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

  • by bidiu,

    bidiu bidiu Feb 10, 2016 9:23 PM in response to AndreasBSweden
    Level 1 (1 points)
    Feb 10, 2016 9:23 PM in response to AndreasBSweden

    Yeah, until now I still haven't solved this issue, which is a kind of awkward.

     

    And we really share the same idea, hoping Apple can do something in the future. Ironically, though, it appears that only Apple developers have the access to report system-level bugs to Apple directly.

  • by VikingOSX,

    VikingOSX VikingOSX Feb 11, 2016 6:25 AM in response to bidiu
    Level 7 (20,591 points)
    Mac OS X
    Feb 11, 2016 6:25 AM in response to bidiu

    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.

  • by Hiroto,Helpful

    Hiroto Hiroto May 7, 2016 9:48 PM in response to VikingOSX
    Level 5 (7,276 points)
    May 7, 2016 9:48 PM in response to VikingOSX

    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

  • by VikingOSX,

    VikingOSX VikingOSX Feb 12, 2016 2:30 AM in response to Hiroto
    Level 7 (20,591 points)
    Mac OS X
    Feb 12, 2016 2:30 AM in response to Hiroto

    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.

  • by Hiroto,

    Hiroto Hiroto Feb 12, 2016 3:48 AM in response to VikingOSX
    Level 5 (7,276 points)
    Feb 12, 2016 3:48 AM in response to VikingOSX

    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

  • by bidiu,

    bidiu bidiu Feb 12, 2016 7:34 AM in response to VikingOSX
    Level 1 (1 points)
    Feb 12, 2016 7:34 AM in response to VikingOSX

    Hi,

     

    thanks for your reply. So you mean the only thing I can do at this point is to reinstall my OS? Because OS X is an UNIX-based system, there's nothing I can do to work around this kernel stuff?

  • by VikingOSX,

    VikingOSX VikingOSX Feb 12, 2016 8:03 AM in response to Hiroto
    Level 7 (20,591 points)
    Mac OS X
    Feb 12, 2016 8:03 AM in response to Hiroto

    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.

  • by VikingOSX,

    VikingOSX VikingOSX Feb 12, 2016 8:15 AM in response to bidiu
    Level 7 (20,591 points)
    Mac OS X
    Feb 12, 2016 8:15 AM in response to bidiu

    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.

  • by VikingOSX,

    VikingOSX VikingOSX Feb 12, 2016 8:40 AM in response to VikingOSX
    Level 7 (20,591 points)
    Mac OS X
    Feb 12, 2016 8:40 AM in response to VikingOSX

    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.

  • by VikingOSX,

    VikingOSX VikingOSX Feb 12, 2016 8:53 AM in response to bidiu
    Level 7 (20,591 points)
    Mac OS X
    Feb 12, 2016 8:53 AM in response to bidiu

    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.

  • by To_Mi,

    To_Mi To_Mi Feb 12, 2016 10:07 AM in response to bidiu
    Level 2 (351 points)
    iLife
    Feb 12, 2016 10:07 AM in response to bidiu

    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.

  • by rccharles,

    rccharles rccharles Feb 12, 2016 11:28 AM in response to To_Mi
    Level 6 (8,459 points)
    Classic Mac OS
    Feb 12, 2016 11:28 AM in response to To_Mi

    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

  • by To_Mi,Solvedanswer

    To_Mi To_Mi Feb 12, 2016 4:50 PM in response to To_Mi
    Level 2 (351 points)
    iLife
    Feb 12, 2016 4:50 PM in response to To_Mi

    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.

Previous Page 2 of 3 last Next