"open with" duplicate entries

TOAO wrote:

All who have made these posts, have experienced a similar problem.

Is it technically rational to demand that ALL symptoms be perfectly identical among machines that are not identical?

All posting here (except macjack) have experienced the same basic symptom: duplicate 'open with' entries. However, the condition(s) that give rise to this symptom vary greatly. For most (but not all) the necessary condition is a clone is or has been attached to their system. The symptom may appear on mounting the clone, or on unmounting or ejecting the clone, but usually not every time either event occurs.

For some, it appears that this occurs (only?) when there is a mismatch between the currently running OS & the OS on the clone (like running ML & attaching a clone with a Snow Leopard system on it). For others, this apparently isn't true. For at least one user, the symptom occurs with a Time Machine backup rather than a true clone.

Regarding the symptom itself, there seems to be quite a bit of variation in exactly what apps are duplicated, & in some cases how many times they are.

While I fully agree that it is not "technically rational" to demand that all of these things must be identical, I also believe it is not rational to completely ignore these differences when looking for a cause or cure (or workaround) for this problem.

Otherwise, (as I know all too well from personal experience!) it is too easy to overlook something important or jump to hasty conclusions.😊

Interesting.

You just stated what I painstakingly defined.

The problem exists, among all who make backup clones.

The "treatment" (not a cure) varies between machines but is most consistently treated by manipulating the OS.

Manipulation of the OS to treat a recurring problem is an OS Bug by technical definition.

The problem is consistently repeatable on Mountain Lion but can appear in some rare conditions on other versions of operating systems installed on Intel Macs and non existent on PPC Macs.

Evidence that is in no way a "hasty conclusion" due to consistent repeatability and consistent persistence.

What has not been ignored is that there is a dynamic factor involved, thus revealing that the error in the OS is subject to minor changes.

With regard to stimulus and reaction, the Launcher list is directly subject to dynamic change.

The dynamic program that lists launchable applications.

There is no indication of "mismatch" between source and clone as the problem, in fact the problem appears to arise from there being No Mismatch.

As far apps duplicated, there is no inconsistency. All apps on the clone are "duplicate open with".

What I have not witnessed is a person who mounts an identical ML hard drive Not created by cloning from the exact same machine. (A VERY SPECIFIC CONDITION)

Since this problem is only an annoyance, I have not taken the time to do this and it remains my final test.

The true test being duplicate installations of identical software not included in the ML install.

Within all of these posts is an obvious tendency to leave out the tiny critical details.

Therefore:

I must control all details in my tests and specify that my results are specific to one machine only.

That IS what I have done.

The most overlooked detail in all of this is networking activity and networking activity causes dynamic changes to the Launcher list.

Dynamic changes can include "some" application update installs, for example Perfect Photo 7 Premium Suite caused a triplicate "open with" WITHOUT being cloned.

That was my first indication that the problem can exist by merely mounting a clone or hard drive with ML installed.

I do take offense at the accusation that I have hastily jumped to a conclusion, since that polite and diplomatic attack IS psycho babble excrement.

To make such statements and analysis, you really should conduct your own controlled experiments rather than apply analysis to speculation.😝

TOAO wrote:

The problem exists, among all who make backup clones.

Not true. See for instance macjack's first post in this dicussion.

As far apps duplicated, there is no inconsistency. All apps on the clone are "duplicate open with".

Also not true. See for example the screen shot justin_case posted back in November in this topic. Or check this screen shot from a non-ASC source, one of several a web search will reveal. And on my new 2012 model iMac, I see the same thing: some apps that I know for certain are on both the clone & the boot drive are duplicated while others are not.

The most overlooked detail in all of this is networking activity and networking activity causes dynamic changes to the Launcher list.

But that has been true at least since Tiger. What you call the "Launcher list" is technically referred to as the Launch Services database. If you are interested in how Launch Services works, check out this overview, particularly the references to URL's.

The lsregister utility used in the Terminal command fixes mentioned here & elsewhere is an Apple-provided tool for examining & manipulating this database. (See for example this web page for a description of its capabilities.) Note in particular that the Terminal fix (whether temporary or not) works without inclusion of the network domain option. It isn't that the network's possible role in this has been overlooked, it is that it apparently plays no role.

Dynamic changes can include "some" application update installs, for example Perfect Photo 7 Premium Suite caused a triplicate "open with" WITHOUT being cloned.

As the above reference should make clear, any well behaved app update should register itself with Launch Services. Again, this is true for every version of OS X, not just ML.

I do take offense at the accusation that I have hastily jumped to a conclusion, since that polite and diplomatic attack IS psycho babble excrement.

I'm not attacking you. I am just pointing out some things you have overlooked, both in the comments of others in this thread & in what is readily available from many other sources on the web. I appreciate that you are trying to limit your comments to what you have seen by running controlled tests on your Mac, but please don't lose sight of the fact that your contribution is just one among many to an issue with a long & puzzling history.

I read through the entire thread, but I am not sure this already settled: The problem is not limited to machines running cloining software. I don't run such applications and still have the problem on my macBook Pro running 10.8.2.

In my case using the freeware Onyx (http://www.titanium.free.fr) to Rebuild the Launch Services database (Maintenance tab) did resolve the issue. Installing updates might make the problem come back later on, but using Onyx feels slightly easier than a terminal command. As said is this thread, this is merely treating the symptom, not removing the cause, so I additionally left feedback to Apple.

duplicate programs listed in "Open With" menu

duplicate "Open With" options - how to get rid of them?

I this was merely a rehash of things said earlier in this thread, please forgive my intrusion.

ya_shin wrote:

I read through the entire thread, but I am not sure this already settled: The problem is not limited to machines running cloining software.

Nor is it limited to machines running Mountain Lion, as your links show. The traditional approach to removing the duplicates is the same for all OS X versions: force the OS to rebuild the Launch Services database.

Onyx is one of several third party utilities that will do this, typically by providing a GUI "front end" to run the same lsregister command line tool built into the OS that can be run manually via Terminal. It is no more or less effective than the Terminal version; it just avoids the need to type in that long string of text (including the correct path to the tool, which varies by OS version) to use it.

You can even make your own customized utility to rebuild or examine the database. There are a few examples of this on the web. I'm playing with one now that uses an AppleScript "front end" to run the lsregister tool. By using the "dump" instead of "kill" option, it should be possible to see which app bundles have duplicate database entries, which may provide some clue about why that happens.

If I get this going & it provides anything interesting, I will be sure to post that here.

Good Grief!

What part part of I am reporting ALL of my experiences with this problem is not clear????

MY firsthand experiences with Tiger, Leopard, (PPC only) and Snow Leopard and Mountain Lion.

(I wisely avoided Lion like the plague and NONE of my system installs are updates)

My approach is very SIMPLE.

I refuse to use ANY other app or utility that is not part of the OS because if I do, I manipulate a test that is being conducted to determine if an annoying bug in the OS exists.

What I experienced is that a radical change occurred in Mountain Lion that is not a rare exception.

I did not treat the problem as so many others have done because treating the problem DOES NOT FIX the problem.

Bipolar Reasoning and Bipolar Logic states that I can program an app not installed on the system to control this problem and then refuses to admit that an OS with no problem does not require any manipulation.

(it makes no difference what extraneous program is used to control the problem or who wrote it or how much it costs.... the problem exists)

My FIX, which is PERMANENT was extremely simple and was part of my diagnostic test routine.

I switched to Snow Leopard, and made an exact duplicate of the ML system right down to each and every user file. (somewhat complex since each App had to be both SL and ML compatible, AND same version)

The ONLY difference between the two is the Operating System.

I then tried to duplicate the problem witnessed in ML, and it does not exist in SL.

Gee!, what does that mean without any debate?

Evidently I have not failed to realize anything and I am once again subjected to a person who ASSUMES that I am incompetent. (this is called applying analysis to speculation and it is directly offensive)

What I have reported is total fact with regard to my firsthand experiences, I have no reason to debate any part of this.

All that I can state is that my experiences are specific to a Mac Pro mid 2012 in VERIFIED perfect working order.

I cannot rationally speculate on any other set of conditions because I cannot know what the test controls are.

The only sidenote I can submit is with regard to external cloned drives.

Ejecting an external clone does not electrically disconnect it.

Make certain it is powered down when finished.

I am a hardware engineer, not a software weenie.

My software terminologies (semantics) may be questionable.

What I refer to as the Launcher list indicated in ML had an ".afl" modification in its filename as compared to Snow Leopard.

My only "programming" experience (or care for that matter) was machine language and assembly code.

Ever seen a computer that operates without an operating system or software of any kind?

I have.

No Doubt, my terms / semantics are questionable. I don't hack operating systems.

ONE MORE TIME....

ALL my references and reports are specific to Mac Pro mid 2012 and experienced first hand.

Make no other assertion please. Crucifying me will help achieve what????

Offending me with diplomatic accusations of incompetence and prevarication has not changed a thing.

After all...

I made my reports hoping to seek a CURE to this problem that is Only an Annoyance and does not affect operation. (I stated my unfamilarity clearly)

The answer is:

There is no cure unless Apple fixes it.

All else is superfluous bipolar babble that proves a problem exists.

(for example.... download this program and program it to control this Bug,... run this terminal command every time this Bug appears)

ANY action the user must take to modify the Operating System to eliminate ANY "recurring" problem IS defined as a Bug. (unless I am speaking to OJ's lawyer)

What is the difference between the words treatment and cure?

Thanks macjack, this worked perfectly on 10.8.2. Just after running that command I ran:

killall Finder

And now my problems are solved.

I wrote:

If I get this going & it provides anything interesting, I will be sure to post that here.

I have made a little progress with this. I have been using a shell script to check the entries in the Launch Services database. It is slow going because I can't find a reliable "trigger" to cause the duplicate "open with" items to appear on my iMac, so I'm limited to testing whenever it happens, which seems to occur at random & infrequent intervals.

For instance, it doesn't occur every time I connect a clone to the system. It has happened once when I connected a Time Machine backup drive, but only once. It also happened once when no other drives or volumes were connected besides the startup disk.

Anyway, what I have found from the last occurrence is in that instance one set of duplicates comes from path /Volumes/Macintosh HD 1/ & exactly matches the entries at path "/" (the UNIX notation for the root level of the startup disk, in my case the disk named "Macintosh HD"). The /Volumes/ folder normally has just an alias to the startup drive, & it did in this case too, but apparently something is causing Launch Services to see it also as a second mounted volume named "Macintosh HD 1."

There is some mention of the /Volumes/ folder misbehaving in this way from various sources on the web. As time permits I'm looking into that for clues about possible causes for that behavior. So far, I have found nothing very enlightening, other than it is something not unique to Mountain Lion.

If I find out anything more useful, I will be sure to post it here.

I don't know if this is any help but will share it regardless.

On a Mac Pro mid 2012, this problem ALWAYS appears every time I make or update a clone.

There has not been one single exception.

It has also occurred every time I mount a clone, there has been no exception.

My first THEORY remains to be proven and I have simply not had the time.

My first theory was that the cloning software had to make a modification to the operating system in order to duplicate invisible files that had been modified.

The theory was that the cloning software did not restore the invisible files to their proper format once finished cloning.

My first effort was to utilize Disk Permissions Repair and this worked very well if the clone was ejected and powered down and of course computer restarted as I detailed.

THEN, that method failed to work once, indicating that something else was happening.

Taking account of all possible details.... the only other processes that had occurred were all networking of some sort including checking for application updates.

That was the only other possible source of modification because the Control was to do nothing else.

What remains as a reliable test is to install ML on a blank hard drive (not cloned) and see if the problem occurs when mounting an external clone while booted on the clean ML install.

My first step was very simple.

Reinstall ML on to the drive that was in a verified state of "duplicate open with".

When I performed this rather time consuming test, the problem went away.... until I made another clone or updated a clone.

In other words, I can remove the problem by reinstalling ML and by other means but it is not solved or fixed and has always recurred.

I failed to write down the files repaired when using Repair Disk Permissions.... WHEN Repair Permissions actually worked. Woops! (I will do that next time)

Using Repair Disk Permissions indicated what files had been changed during the cloning process and pointed at the source of the trouble.

In the meantime.... my switch to Snow Leopard has completely eliminated the problem that is not really a problem, its just an annoyance. (6 clone updates so far, and not one problem)

The is a very real possibility that my conditions are simply not identical because both the operating system and computer firmware between machines are not identical.

No surprise that symptoms vary quite a bit. (my Mac Pro runs 8 internal non partitioned physical hard drives and can have as many as 10, most other Apple devices run 1 internal drive that may or may not have partitions.... in other words.... the firmware on a Mac Pro is not the same as that on an iMac, laptop, iPad, or MacMini)

The only process I share in common was self evident.

I had no reason to make a clone unless there was an operating system or application update.... in other words.... networking activity. (I do not keep any of my personal files on my operating system hard drive due to classification.... all I ever clone is OS and App updates)

With any luck, sharing my experiences may help somebody who is familiar with hacking operating systems and ultimately give Apple a solution to this "annoyance".

The considerations in Mountain Lion that must be realized and are the potential source of the problem and its variations are.

1. Power Nap.

2. Gatekeeper.

3. Sandbox.

4, XD processor code not present in "all" machines.

For these unique to Mountain Lion and unique to machine firmware and unique to processor OS programs to function, the system MUST index and compare all apps that appear in external drives and network processes.

This directly affects the function of "Open With" and IS unique to Mountain Lion and to some extent Lion AND unique to machine. (symptoms WILL vary and MUST)

Another potential source of randomness is a radical change in Mountain Lion that places the Ram locations of OS execution in "random" locations in Ram upon every restart. (this is an anti malware feature only present in Mountain Lion and is effective but does cause some odd things to occur with respect to Apps not "fully" compliant)

The random occurrences of this appearing in other OS versions becomes random occurrence with one verifiable and repeatable process that eliminates the random occurrence in Snow Leopard on a Mac Pro mid 2012 and does, on occasion, work equally as well in Mountain Lion on the same Mac Pro machine.

The problem seldom if ever occurs in SL and IS easily fixed using Repair Disk Permissions once the external drive is ejected and powered down and computer restarted.

Unless ALL of these factors are considered and realized, the problem will appear inconsistent when in fact its not.

If anybody wants to try checking the Lauch Services database to see where the duplicate application entries are coming from, you might be interested in this (rather formidable looking!) Terminal command that will output a long list of the full pathnames of every application in the database:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump | grep --after-context 1 "^bundle" | grep --only-matching "/.*\.app"

To use it, copy the whole thing & paste it into a Terminal window (it is one long line).

Note: the ASC forum software seems to add a return to the end of the command when copied, so as is it will execute immediately when you paste it into Terminal. If you would prefer to avoid that, paste it instead into TextEdit & then copy everything up to & including the final quotation mark but not the beginning of the next line from the TextEdit window & paste that into Terminal.

You can then search or scroll through the list looking for duplicate app names at different paths. You should see one set all with path names beginning with "/Applications/," corresponding to all the apps in your startup disk. If you have duplicates, they should be at another path, like ones beginning with "/Volumes/" followed by the name of the volume they come from.

This may help pin down where the duplicates are coming from. If not, it is at least interesting to see how many more apps there are in the database than you might expect, even if you have no duplicates! 😎

BTW, I did not write the command but I have tested it extensively & it should work with any system running Snow Leopard or later. (It should work with earlier versions too, but the path to lsregister in the first part of the command will have to be modified because the path to it is different in older OS versions.)

Should you be wondering, it does not change anything in the system. The "dump" option just reads the complete contents of the database; the two "grep" commands just filter out everything besides the pathnames. (If you want, you can copy just everything up to but not including the first vertical stroke & get the entire database contents, but that produces a lot of information not needed if you just want to look at the application names.)

Also note that the lsregister utility is built into the OS itself, as is the grep filter. You aren't relying on any third party add on software for this.

Thanks.

That certainly seems helpful AND interesting.

Much appreciated.

Will this Terminal Command identify all the sources that generated the Launch Services list or just the path names?

I have personally no use for this command since I reported this annoyance to Apple formally and believe that Apple will address the issue in future updates.

This "duplicate open with" issue has not demonstrated any flaw in system operation that I have detected and is very low on my list of things to do.

(specifically, I have not tried to launch any other application except the cloning app with a clone mounted and do not have this intention or need.... I do not laucnh the clone app using "open with")

To date, it has made no difference if I select a "duplicate open with" when the clone is not mounted, it always launches the only app available. (the correct app)

That is one test I do not intend to perform. (attempt to launch an app from a mounted clone)

I find this Terminal Command you shared Very Useful in one respect.

It clearly shows that the Launch Services list is not being refreshed upon external device eject as previously defined.

This is not the only dynamic file in Mountain Lion that is not being refreshed when it should be.

For those interested,.... this "open with" annoyance does not occur on a Mac Pro mid 2012 running Snow Leopard, HOWEVER, failure to refresh and or apply Network Settings is common to both SL and ML.

(only difference is that ML applies a network transceiver enable upon entering sleep mode and SL does not)

In short.... network transceivers can only be Disabled Manually and must be manually Disabled upon Wake and or Restart.... Every Time.... the machine wakes up or is restarted no matter what the Network Settings are.

(to repeat myself.... the only difference is that ML will enable the transceivers upon entering sleep mode no matter what settings you use and SL does not)

Note, this can only be verified by checking the Hardware itself, not the software.

THAT.... IS a problem.

It is a wide open door that says, Hack Me.

Will this Terminal Command identify all the sources that generated the Launch Services list or just the path names?

A UNIX path name is the path to its source.

That's great news!

So specifically which OS module or program is creating the "duplicate open with" annoyance?

TOAO wrote:

So specifically which OS module or program is creating the "duplicate open with" annoyance?

As I explained earlier, in my case the duplicate entries came from a "phantom" of the startup disk at path /Volumes/Macintosh HD 1/. The normally hidden Volumes folder is the mount point for all attached volumes. (You can see this in Disk Utility by selecting a volume name on the left. At the bottom of the window, you will see a line showing its mount point in UNIX notation.)

The Volumes folder entry for the startup disk is an alias. By convention, it is listed at mount point "/" -- IOW, without the "/Volumes/{name of startup volume}" part. Terminal follows this same UNIX convention, so for example the path name to Safari in the Applications folder of the startup drive shows up as "/Applications/Safari.app" in the results of the command.

My startup disk has the default "Macintosh HD" name so while the full path to its Applications folder really is /Volumes/Macintosh HD/Applications/ all the apps in it just show a path name beginning with /Applications/. That the Launch Services database had a duplicate set at path /Volumes/Macintosh HD 1/ implies that something caused a duplicate of the startup volume to appear in the Volumes folder with a name appended with a " 1" suffix (because two items can't have the same name in the same folder).

There are several things known to cause something like this to happen. See for example the blue section of Time Machine guru Pondini's Where did my Disk Space go? page or this old Tidbits article. None are unique to Mountain Lion but perhaps there is something about ML that makes one of these causes more likely to occur.

But that's just a guess. As I mentioned in a much earlier post, it is still possible that in at least some cases the glitch is caused by (for instance) the cloning software, as Pondini's article mentions. It may be that on occasion some process tries to write to the startup drive while the clone is being created or updated & instead writes to a newly created Volumes folder. Creating a clone of a "live" startup volume is quite tricky since its contents can change during that process, so it is at least a plausible cause, if admittedly not one anybody seems to understand very well.

But regardless of all that, I want to emphasize that my results from the command may be quite different from what someone else gets. It is clear from the posts to this topic that there are several different triggers that can cause this issue to occur at different times for different users. For some, the problem may have nothing to do with the Volumes folder. The only thing I can suggest is to try the command while the duplicate 'open with' items are present & see if the results are similar to mine.