Slow file open dialogue box

I provided my feedback and reported it via the about one week into using Mavericks (I had hoped it was a caching issue, or, if a bug, something that had been around and a quick fix would be released for) after 10.9 went GA, and then the AppleCare rep said they would also report it to their developers (right...). But, like most other incredibly quirky foundational issues that I may actually call them for help with, it's "news to them" and they almost always have never heard of what I am asking them for help with (or so they claim)... So, I agree, the more feedback the better. I hope your reference to NDA means you know something good is coming, but, I will not press you for anymore info 🙂

superjones wrote:

after 10.9 went GA,

and then the AppleCare rep said they would also report it to their developers (right...).

Haven't seen 'GA' since I left the mainframe developer business. Thanks for memory.

In my experience many developement fixes were driven by the quantity of issues reported to the frontline support folks. That might happen with AppleCare if they are opening support tickets that get tracked. There is usually someone watching the support metrics.

I would be very grateful if someone could go into slightly more detail about this workaround. I'm not scared of going into Terminal, but I'm not familiar with "commenting out" items, or what buttons to press in order to facilitate these commands. Any additional explainations are appreciated tremendously!

Thanks!

atpyburn wrote:

what are the steps between commenting out and sudo automount -vc?

My post in this thread on Nov. 20th shows steps using TextWrangler ( a text editor ). Is this enough detail?

At a high-level the steps are:

(1) Launch a text editor like TextWrangler and edit the file and make the change noted

(2) Save the file from within the text editor

(3) Exit the text editor ( not required but you don't need it after the edit is complete )

(4) Launch Terminal.app

(5) enter the 'sudo automount -vc' command in Terminal

(6) exit Terminal app

As others have already noted, be careful not to change the file type ( TextWrangler won't ). Making a copy of the file before you make changes is wise but probably overkill since this simple change can be easily backed out.

atpyburn wrote:

but I'm not familiar with "commenting out" items

"commenting out" is programmer's terminology for making an active line of code inactive. It typically means a language compiler ( such as C, Objective-C, Fortran etc. ) ignores the line of code when an app it is built ( i.e. compiled and linked ). In this particular case 'automount' consults the auto_master file and ignores any lines prefixed with the pound sign ( # ). The reason for "commenting out" is most languages have a symbol to deactive a line of code or to write comments describing the function of the code. So deactivating turns it into a comment ---thus commenting out.

Stumbled into this thread after experiencing this problem with Finder being slow. I've seen it for months now and figured it was due to some system file being corrupted on my old Mac. I've now got a pristine new system and the old system completely refreshed to give away for Christmas gift. Anyhow, both systems are exhibiting this behavior. Taking way too long to simply list files in a folder. I was finally driven here when even applications like SublimeText are failing to list project files... surely rooted in the same Finder problem.

Here's another tidbit I've noticed. Every time Finder does it's little busying thing, my firewall is revealing it is sending out packets. What is up with that, and what does

"I can't say too much due to NDAs" mean?

Michael Prescott wrote:

...what does "I can't say too much due to NDAs" mean?

NDA = Non-Disclosure Agreement - a binding legal agreement between Apple and developers.

Apple's Developer Program allows developers to download unreleased/in-development ( i.e. alpha/beta stages ) Apple software ( typically OS X and developer tools ). The program requires: (1) a membership fee ( $99 ) and (2) legally forbids disclosure to the public of anything the developer might find during testing of Apple's beta software.

So those comments mean the developer knows whether the upcoming OS X point release solves a problem but is compelled to not reveal it.

I see. Thanks! That's good news, I think.

I expected this new system to be amazingly fast, but this Finder bug is ubiquitous. Affecting every application, every operation. It'll be a relief to have it fixed.

Yeah. For such an annoying issue that affected every application that opens or saves files from/to disk, it was indeed nice to see a mention of "NDA" regarding this issue and its workaround prior to the release of 10.9.1. Too bad it was not fixed with 10.9.1...

It is strange to me that an issue like this made it through all of the developer testing, GM, GA, and still with the first major update. Did not a single tester or Apple developer work on figuring this out for months upon months? Maybe no one tried opening or saving a file with any application during testing? Did 10.9 follow the waterfall model with very little emphasis on V&V?

I have reported several bugs for 10.9, I have worked with Apple Care, and developers focus on whatever and Apple Care support engineers know nothing and have provided no resolutions or workarounds. I always find my answers online or on my own when I encounter a problem that isn't documented as FAD in some Apple doc.

OS X is still far and away my preferred OS for personal use, but I must say that I am growing somewhat dissatisfied with the lack of meaningful updates for OS X 10.9 that address real issues that impact a most if not all users. Two updates from Apple released with fixes for Gmail connectivity means nothing to me as I have never had any issues with Thunderbird connecting to Gmail (even when left open and accessing Gmail on my iPad and/or iPhone) or any other IMAP or POP3 email server ever -- using OS X Mail is like using Outlook Express and if there are problems using Gmail with the default Mail.app, then let users find and use something better. It seems to me that problems for some users a stock OS email client working with a Google service is not as big of a priority as the fastest of the fastest computers taking many seconds to display the contents of indexed folders. And what about choppy animation for Disk Utility when launched (not to mention the missing "OK" message when verifying the primary disk/partition), or timing of authentication for Twitter and iMessage when Notification Center first launches, and why such an increased memory footprint for kernel_task and the seemingly unusual memory consumed by com.apple.IconServicesAgent, and so on?

The task of resolving systemic issues that affect most or all users of OS X should not always result in workarounds discovered and delivered by the user community. Maybe 10.9.2 will fix some things, or maybe the most meaningful change delivered will just be a buggy initial iteration of FaceTime Audio for OS X.

This issue lasting this long has been very irritating and this is all I have to say about it for now. I remain thankful that someone was able to discover and share a workaround while Apple's own support and developers did and do nothing.

From my lay perspective, it seems Apple is working to move everything to the cloud rather than just providing clearly controllable options to enable cloud features. It appears that at least a small amount data is going out of local network with every single file operation. That this "bug" is less of a bug and more of a feature that is being actively developed. That might explain well how it made it past testing.

How many of the posters have iCloud turned off on their machine? Maybe ( and this is only a WAG with no real evidence to support it ) some of Apple's code assumes it is turned on. In my case iCloud is intentionally turned off.

The reason this "bug" made it through all the testing is that it is almost certainly a configuration issue unique to the machines exhibiting the problem, not an actual bug in OS X. The workaround causes the automounter to skip mounting network volumes, so the issue is almost certainly related to a configured network share - likely a share that is no longer present for the computer to mount. Speculating - but possibly Finder is trying to follow aliases to remote volumes that are not responding or are responding slowly.

Eric Hildum wrote:

The reason this "bug" made it through all the testing is that it is almost certainly a configuration issue unique to the machines exhibiting the problem, not an actual bug in OS X. The workaround causes the automounter to skip mounting network volumes, so the issue is almost certainly related to a configured network share - likely a share that is no longer present for the computer to mount. Speculating - but possibly Finder is trying to follow aliases to remote volumes that are not responding or are responding slowly.

A reasonable diagnosis but it doesn't match my circumstances and perhaps others too. There have never been any network shares attached to this Mac. I do mount some local external volumes ( and later eject them ) for clone backup. It is a standalone Mac.

The live entries in my /etc/autofs.conf are:

AUTOMOUNT_TIMEOUT=3600

AUTOMOUNTD_MNTOPTS=nosuid,nodev

AUTOMOUNTD_NOSUID=TRUE

Thanks for the input Eric.

Sure sounds like a bug to me. These complaints are coming from users who aren't using shares. We are just using the default configuration files that come with a virgin install of Mavericks! No such problem existed in 10.8.x.