"open with" duplicate entries

Seems like the test I defined will tell the story.

Like we both agree upon....

There is a chance that the new complexities of ML cause an annoyance to occur when cloned.

The only way to refine focus is to create two identical hard drives via the Installer instead of cloning.

Then mount the identical non clone with a drive that is not cloned and see if ML produces the "duplicate open with" annoyance. (only apps installed would be Apple apps)

This would place the source within the OS and or by default, indicate the cloning software.

I have not found time to do this nor can I justify the expense because it is not producing any functional errors.

What I have done is test to see if the ML reinstall process clears the problem. (a slow process)

The answer to that test was Yes and No.

It clears the problem until the external clone is updated and or mounted.

Since my Mac Pro is Not attached to a network normally, the only time it is attached to a network is to look for OS and App updates.

Updates that are then cloned.

Seems that I need to check for this annoyance without making any updates or changes and I have not yet done this because there has been an endless march of updates. (not present in Snow Leopard)

This leaves only one other diagnostic test.

Reinstall ML on both the internal drive and external clone.

(very easily accomplished on a Mac Pro by internal drive removal and replacement)

Then.... see if this annoyance occurs.

(the idea is to avoid reinstalling several thousand dollars worth of apps and reactivating them OR avoid buying two blank hard drives just to check clean non cloned ML installs..... REGARDLESS.... this "bug" is just an annoyance and I have not seen a report where it actually causes a problem, nor have I experienced any problem, please pardon my lack of motivation)

If we are to help repair this annoyance, we need to identify the source, the Path to a dynamic file is not the source.

The CODE that produces the dynamic file and its path is the source.

The CODE does not refresh the dynamic file when an external drive is ejected.

Since my Mac Pro is Not attached to a network normally, the only time it is attached to a network is to look for OS and App updates.

Do you have this same issue with the computer you use to post messages here?

I have 10 Macs, all operational, only one is attached to a network, my "sacrificial" Mac.

ALL are desktop computers.

Out of the 10, the only one with this annoyance is the one with Mountain Lion installed.

I have not experienced this problem personally with any PPC Mac and no Intel Mac with Snow Leopard installed.

The Mac I use on the net does not have this annoyance, it is running Leopard.

In fact, it does not have the Network Settings problem either.

As I have already gathered.... symptoms vary.

The only commonality among these machines that do not have this annoyance is that the machines are not network attached with one exception.

The Snow Leopard machine is only attached "rarely" and does not have the problem.

(sadly, Mountain Lion is anything but debugged and periodic update checks are required)

Snow Leopard has had only two updates, both Java. (which I did not actually require unless network attached)

My Leopard machines have not had an update in years and neither has the installed software.

While they are exceptionally stable.... they are also quite limited due to advancements in software and rapidly becoming unusable on the internet. (Oh Well.... they work wonderfully)

At the absolute minimum I had to update to Snow Leopard and chose Mountain Lion as my best choice for network activities.

As it works out, not my best choice for anything else.

Mountain Lion has turned my Mac Pro into an "idevice" and spends so much background effort in pre-preparing files for web transfer that compared to Snow Leopard it is typically 30% less efficient. (enough that the user requires no benchmarking tools to easily detect a decrease in performance running identical versions of apps)

My "setup" is not what would be defined as typical.

My actual profession is Energy Physics Research and due to this field of study, my file drive must remain physically electrically separated from my system drive if ANY connection to a network is made. (desktop machines with removable drives or external drives is mandatory)

As far as how this affects or pertains to this problem is irrelevant since a system drive with no personal files has the same problem as I have witnessed.

.... and No.... this field of study requires no working knowledge of a computer's operating system software except how to operate it if needed. (computers do not create research, they record it, the exact opposite of what Hollyweird movies would have a person believe.... but I trust you already know that)

Long story short.

I have never experienced this problem with any Desktop Mac except the one with ML installed.

(this evidently does not hold absolutely true for others)

This machine I am using cannot be used as a baseline study for it is somewhat different than my other standalone machines both in hardware and software. (therefore the answer that "no" this machine does not have this problem becomes irrelevant and could be misleading.... all my posts are relevant to a Mac Pro mid 2012 running ML and no other)

Probably don't need to say this.... fully 90% of the internet is a festering heap of dung and those vidiots out there are doing nothing but slowing down those of us trying to accomplish something tangible and beneficial. What I have witnessed typically is rampant theft of intellectual property and serious waste of time.

Next thing I know, my food processor will require an internet connection for activation.

Funny isn't it.... the first home computers were not used for socializing, they were used for what they were designed for.

Pictures

Movies

Music

Documents / typewriters

Calculators

Art

Design / CAD / Research

and not one of these processes required a network...........not any more!

(this evidently does not hold absolutely true for others)

And that is what makes it so hard to troubleshoot. 😟

All I know for certain is the duplicate 'open with' issue goes back at least as far as Tiger & that the traditional way to fix it (if sometimes only temporarily) is to force the OS to rebuild the Launch Services database.

Beyond that, nothing is certain. Some OS versions seem less prone to this, but that just may be because the conditions that trigger it are more likely to occur with one OS version than another. It doesn't seem to have anything to do only with clones, network connectivity, or any other single identifiable cause -- for example, some users that have never ever cloned a drive sometimes see this occur while others that do it all the time never do.

It is for this reason that I suggested using the Terminal command I posted earlier. If enough users try that, it might yield a clue about the cause of the duplicates, but of course there is no guarantee that it will.

Agreed, it is hard to locate the source when the trouble is dynamic in nature.

This is why I shared my experiences.

A dynamic problem requires that a set of test controls be applied until a repeated and repeatable pattern emerges.

Nobody has shared their symptoms with any detailed set of test controls. (too superficial)

I have tried to do this and will (time permitting) do just that.... but in the end.... it will only apply to a Mac Pro mid 2012.

Not all computers are the same.

PERSPECTIVE

This is the perspective I am working under with regard to what I have experienced under controlled conditions.

(more controlled conditions are required)

A properly working cloning software makes an identical clone.

The OS is supposed to list all possible launchable application under the Open With contextual command.

An endless "Do Loop" is created from two sources.

1. The cloning software is supposed to clone all dynamic files and by default these dynamic files have a "duplicate open with" when the cloned drive is mounted.

2. The OS has failed to create a Refresh for the dynamic file associated to Open With when the clone is ejected and or the Open With command is initiated.

Bottom lines: (under controlled conditions and repeatable on Mac Pro mid 2012)

A "properly functioning cloning program will always have a duplicate open with condition because the clone IS a duplicate.

IF.... a refresh were properly executed in the OS code the problem would not exist.

SOLUTION:

Alter the OS code to execute a refresh upon the Launcher Database file upon Eject, Restart, and or upon initiation of the Open With Contextual Command.

(comically enough.... exactly what the suggested Terminal Command accomplishes manually and must be repeated over and over and over again under controlled conditions)

The myriad of reports clearly define that the symptoms reported are Not reported under controlled conditions.

(random conditions reported from non identical machines)

Placing focus upon that "random" is not beneficial or useful in seeking a solution.

Is the problem always in Tiger, no.

Is the problem always in Leopard, no.

Is the problem always in Snow Leopard, no.

Is the problem always in Mountain Lion, yes and no. (machine dependant, software dependant, condition dependant)

It is a complete waste of time to debate upon whether or not random exceptions occur within a dynamic file under different versions of OS. (fine if you are a lawyer or a politician)

What is required is testing under hghly controlled and detailed conditions.

Ask me if I have ever witnessed this problem in any other OS among any of my DESKTOP Macs and I will state only the facts witnessed. NO.

Crucifying my response achieves what?

Accusations that I made a false statement of fact achieves what?

Stating that this problem exists in ALL Apple OS versions achieves WHAT?

It seems an argument is being sought for no good reason when the discussion is an argument upon how many OS's experience this problem. (mindless aggression resulting in offense that achieves nothing useful.... a soap opera.... guess that's why I became a scientist instead of a politician or a lawyer)

(there is nothing "traditional" about running Terminal Commands except among Operating System OS hackers.... the vast and overwhelming majority of Mac users NEVER open the Terminal Application or have a clue what it is.... I have used Macs since their inception and NEVER used Terminal once until Now, didn't even know it existed.... I have however designed hardware modifications utilizing the CPU, hardware dictates ALL software)

One must always identify one's own PERSPECTIVE.

Excellent fixed it for me. Thanks I was bored and decided to fix this issue today. Found out only took me a few seconds thanks to your post.

Great tip. I was able to confirm that the duplicates in the LS database were coming from an external clone volume that I occasionally have connected for backup. I am pretty sure this is a consqeuence of Spotlight indexing. Unfortunately, adding the volume to the Spotlight privacy tab doesn't seem to work as the setting doesn't stick when I dismount the volume. Interestingly, a similar set up on a Snow Leopard machine does not show the same problem with duplicates (and the volume is not in the Spotlight privacy tab).

By the way, is that Groucho or Mr. Potato Head for your avatar?

I have seen the same oddities between SL and ML.

I am however perplexed by a random inconsistency within ML.

If I have "significant" changes in my backup (application and or system updates and such) I can eliminate the duplicate open with condition by simply ejecting the cloned backup, powering down the clone, and running Repair Disk Permissions.

This works perfectly SOMETIMES but not always.

Either way, the problem is most certainly a failure to update the open with list upon volume eject.

It updates upon mounting the volume, but does not update upon eject.

I guess the next test is to mount a volume that is not a clone, does not contain applications or system and see if the open with list ONLY updates upon a volume mount. (clears the duplicate open with)

I have other things to do at the moment and recently updated to 10.8.3.

Perhaps the problem has been corrected in the latest system update. (I don't know)

My non clone volumes have millions of files and I am waiting to install some hardware updates before I mount those volumes.

Until then, someone else can run the non clone volume mount test.

(produce a duplicate open with state then mount a non clone to see if it clears itself upon index)

Since this occurrence is not a show stopper and has not presented itself as any type of system crasher, it is very low on my personal priority list. (I don't launch applications with a backup clone mounted or powered up regardless if ejected)

RT11 guru wrote:

Unfortunately, adding the volume to the Spotlight privacy tab doesn't seem to work as the setting doesn't stick when I dismount the volume.

Do you mean it isn't there unless the drive is mounted or doesn't reappear when it is mounted again? The first is normal behavior, or at least it has always done that for as far back as I can remember.

By the way, is that Groucho or Mr. Potato Head for your avatar?

Neither really. It is just something I put together in PhotoShop -- the glasses, nose, eyebrows, & mustache are a PhotoShop stock item (modeled after the joke glasses you can get in novelty shops). I tweaked the image a bit to look decent (I hope) at low resolution.

The duplicate open with is persistent unless cleared.

This applies to a cloned drive. (and some others)

My eventual.... tests will be if this persists when a non clone volume is mounted, a volume without any duplicate system or applications once the duplicate open with state is present.

If the duplicate open with state is not cleared then the problem is.... the open with .plist does not update.

If the duplicate open with state is cleared then the problem is.... the open with .plist ONLY updates when a volume is mounted and does not update when ejected. (an OS bug)

The idea is to isolate why the open with .plist is not updating by forcing an update to occur without any Terminal command.

My next test deals with Finder open with settings.

Select a file, Get Info, then select an alternative app to open the file with.

THEN.... go back and do the same but this time, select Change All similar files to open with the default app.

THEN.... check to see if the duplicate open with state has cleared.

NONE of these tests can be performed with a cloned drive attached in any way.

(ejecting a cloned drive does not disconnect it, it must be powered down completely)

Simple logic.

If a user is to report an OS bug, then all manners of tests must be executed to assist the engineer in identifying and isolating the bug.

This annoyance deals with several OS functions.

Finder, Spotlight, Launch.plist and networking and firmware.

Thus the annoyance contains a certain set of random inconsistencies. (sometimes occurs when an app is updated)

Since Spotlight is subject to the tentacles of the other OS functions it is not likely that Spotlight settings will provide a solution.

The solution remains and requires a change to the OS.

I am seeing the normal behavior (drive only appears in the Privacy settings when it is mounted). I had never used these settings before so I was surprised when the drive dissappeared upon dismounting. In any case, I am told (by someone more expert than myself) that the Launch Services uses its own mechanism to register applications and does not rely on Spotlight. I presume that would mean the Spotlight Privacy settings don't matter for the issue of duplicates. While I haven't had the duplicates appear for the past week, I really doubt this has been fixed. On my Snow Leopard system, with a similar clone volume attached and which is not in the Privacy tab, I don't think I have ever seen duplicates in the "open with" menu.

TwoSonic wrote:

Just relaunch Finder (control+option+click on Finder icon in the Dock) it will work. and dont have to logout or restart.

This solved my problem. Thanks.

I tried doing nothing but relaunching the Finder as a test myself.

By itself, the problem did not go away.

Basically I tried anything that did not require any form of Terminal command except a couple which I have not tried yet.

The problem IS.... the State is produced upon mount and is not cleared upon eject or dismount and most frustrating of all.... the State is inconsistent as though a certain set of random variables must be present.

I have been able to clear the problem using nothing but Repair Disk Permissions 50% of the time and 50% of the time I am forced to use a Terminal command.

It is an OS bug that Apple must repair.

As others have reported, I only have this problem with Mountain Lion and no other OS.

As luck would have it, I have both Snow Leopard and Mountain Lion on the same computer.

What I notice is Leopard (10.5) indexes mounted devices, there is a delay, as indicated as a dot in the spotlight magnifying glass in the menu.

There is also a delay in eject.

Mountain lion does not have this delay. Everything is basically instantaneous.

Perhaps.... the reason there was a delay in Leopard (10.5) is because the launch .plist was refreshing itself upon and before eject.

Perhaps.... this delay in eject or dismount was an annoyance and Apple chose to get rid of that problem by not refreshing the .plist (or current device index) ????.... made all mounts and ejects faster.

This "fix" caused the duplicate open with problem????

As far as Snow Leopard (10.6) is concerned.... I have not experienced any problem at all.

Since my computer is a computer and not a socializing device.... my OS of choice is Snow Leopard.

20% faster than Mountain Lion both on boot and execution because it is not constantly trying to make contact with the social network mother ship in the background.

All of my CAD/CAM runs better on Snow Leopard.

Best OS choice for those who network and or use portables is.... Mountain Lion.

#include <iostream.h>

main()

{

cout << "Hello World!";

return 0;

}

{code}

<hr>