External HDD viewing crashes Finder

Discussion in 'macOS' started by arogge, Nov 10, 2011.

  1. arogge, Nov 10, 2011
    Last edited: Nov 11, 2011

    arogge macrumors 65816

    arogge

    Joined:
    Feb 15, 2002
    Location:
    Tatooine
    #1
    Problem Solved: I deleted the root files in .Trashes, .DS_Store, and .fseventsd and remounted the drive, which returned the Finder windowing behavior to normal.


    I think I just broke something. I plugged in my FireWire hard drive and Finder froze when trying to double click on the drive icon on the Desktop. I had to Force Quit the open applications, and logged out and back in, but the problem persisted. I rebooted, and now something really weird is happening. When I double click on the FireWire drive icon, Finder refreshes the Desktop as if I had asked it to Relaunch the Finder. I ran a Verify Disk, but it checked out as normal. I can hear the drive being cached by Spotlight, I can see it in Disk Utility and Terminal, but Finder refuses to let me open it from its Desktop icon. What am I doing wrong?

    Here's a relevant piece of the crash report when I try to open the hard drive in Spotlight Preferences:


    Exception Type: EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008
    Crashed Thread: 6 Dispatch queue: TFSVolumeInfo::GetSyncGCDQueue

    It looks like a windowing problem. Spotlight can find and open files from the drop-down menu in Finder, but any application that requires a Finder GUI to read the files on the drive causes Finder to crash and refresh. This problem is fortunately not affecting any other disk drives. If I try to click on a Folder found in Spotlight, Finder crashes. If I rename the volume through Finder, it still crashes but accepts the change. It mounts quickly and I can Eject it from another Finder window or by dragging to the Trash. The problem has also affected other OS X profiles. There doesn't seem to be anything wrong with the drive, so the problem is with a specific part of Finder that probably controls the windowing cache.

    This is the top part of the crash report when clicking on the hard drive icon:

    Thread 0 Crashed: Dispatch queue: com.apple.main-thread
    0 com.apple.DesktopServices 0x00007fff81c62e34 BTreeIterator::Next() + 138
    1 com.apple.DesktopServices 0x00007fff81c60b7c TPropertyInfo::MakeProperties(TPropertyInfoList*, unsigned char*, unsigned int, bool) + 414
    2 com.apple.DesktopServices 0x00007fff81c605ff TPropertyInfo::CreatePropertyList(TCountedPtr<TFSInfo> const&, UTCDateTime&, bool, bool, TPropertyInfoList*) + 501
    3 com.apple.DesktopServices 0x00007fff81c603bf TPropertyInfo::CreatePropertyList(TCountedPtr<TCFURLInfo> const&, UTCDateTime&, bool, bool, TPropertyInfoList*) + 175
    4 com.apple.DesktopServices 0x00007fff81c6017f THFSPlusPropertyStore::Open(bool, bool) const + 173
    5 com.apple.DesktopServices 0x00007fff81c600a5 THFSPlusPropertyStore::GetProperties(bool) const + 55
    6 com.apple.DesktopServices 0x00007fff81c5fee1 THFSPlusPropertyStore::GetProperty(TUString const&, unsigned int, TPropertyReference&) const + 85
    7 com.apple.DesktopServices 0x00007fff81c5f59b TNode::GetExtendedProperty(unsigned int, TPropertyReference&, bool) const + 101
    8 com.apple.DesktopServices 0x00007fff81c5d6b0 TNode::GetProperty(unsigned int, TPropertyReference&, OpaqueNodeRequest* const&, unsigned int) const + 116
    9 com.apple.DesktopServices 0x00007fff81c5d5f6 GetNodeProperty(OpaqueNodeRef*, unsigned int, TPropertyReference&, OpaqueNodeRequest*, unsigned int) + 164
    10 com.apple.DesktopServices 0x00007fff81c69c4b NodeGetPropertyAsData + 70
    11 com.apple.finder 0x000000010001ad13 0x100000000 + 109843
    12 com.apple.finder 0x000000010001a455 0x100000000 + 107605
    13 com.apple.finder 0x000000010003c923 0x100000000 + 248099
    14 com.apple.finder 0x00000001000169b7 0x100000000 + 92599
    15 com.apple.finder 0x000000010003be19 0x100000000 + 245273
    16 com.apple.finder 0x000000010003b58b 0x100000000 + 243083
    17 com.apple.finder 0x000000010014bdef 0x100000000 + 1359343
    18 com.apple.finder 0x000000010005e5d7 0x100000000 + 386519
    19 com.apple.finder 0x00000001000c0e9e 0x100000000 + 790174
    20 com.apple.AppKit 0x00007fff86fee3d9 -[NSWindow sendEvent:] + 5547
    21 com.apple.AppKit 0x00007fff86f23a86 -[NSApplication sendEvent:] + 4719
    22 com.apple.AppKit 0x00007fff86eba4da -[NSApplication run] + 474
    23 com.apple.AppKit 0x00007fff86eb31a8 NSApplicationMain + 364
    24 com.apple.finder 0x0000000100005199 0x100000000 + 20889
    25 com.apple.finder 0x000000010000515c 0x100000000 + 20828
     
  2. r0k macrumors 68040

    r0k

    Joined:
    Mar 3, 2008
    Location:
    Detroit
    #2
    You don't need to mount that drive. Please stop.

    -Steve



    (J/K :p )
     
  3. rlphoto macrumors newbie

    Joined:
    Oct 23, 2012
    #3
    I'm at my wit's end dealing with this same problem with a RAID that seems otherwise healthy. From the start of your post below, it sounds like you had the same problem and resolved it but then I read on and am confused by the rest of your post. Did deleting those root files solve the finder crash problem?
     
  4. arogge thread starter macrumors 65816

    arogge

    Joined:
    Feb 15, 2002
    Location:
    Tatooine
    #4
    Yes, I think it did.
     
  5. syth macrumors member

    Joined:
    Jan 10, 2008
    #5
    I removed the files, unounted the drive, remounted the drive, and now I get a different crash:


    Code:
    Crashed Thread:  2  Dispatch queue: TFolderSizingThread::GetFolderSizingQueue
    
    Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
    
    External Modification Warnings:
    Thread creation by external task.
    
    Yay! …

    I went to the remote machine and removed DS_store again, and also .apdisk and .Spotlight-V100, but it still crashes unless I disable the folder-size calculation in the finder.
     

Share This Page