Previous 1 2 3 4 5 6 Next 87 Replies Latest reply: Sep 26, 2014 1:14 AM by shadow Go to original post
  • TOAO Level 1 Level 1

    You said.

    That doesn't completely rule out the possibility that the cloning SW isn't fully compatible with ML.


    The "test" is to clone ML and verify full function of the clone.


    Both Leopard, and Snow Leopard self correct this problem by two methods.

    1. Eject the clone, select the application and launch it.

    2. Eject the clone and restart. Also repeatedly verified.

    Obviously experiences vary based upon not only computer model, but installed software as well.

    I have NEVER experienced this problem with Tiger or Leopard regardless of backup clones. (PPC Mac)

    I have only seen this happen in Snow Leopard once and it self corrected without any third party software.


    Online installation has altered the OS requirements for external application launches in ML.

    This is partly due to the introduction of the App Store combined with online installation requirements and Notifications.

    The actual Bug itself is a condition where the Launcher updates itself when an external source is mounted, but does not refresh the Launcher when the external device is ejected.

    While this works just fine for network connections, it has a bug with respect to hardline devices that contain launchable applications on a GUID formatted drive.


    Faulty cloning software that duplicates a clone with identical UUID that cannot be mounted at the same time as the source is ludicrous since this makes the clone perfectly useless to anyone but a criminal pirate and the flaw in the cloning software IS effectively a form a malware that caused the operating system to function improperly.


    This particular thread is from users who have all experienced the identical problem with minor variations experienced between actual machines and installed applications.

    That is to be expected.

    It should be noted that my posts have all been made with specific reference to a Mac Pro mid 2012 AND NO OTHER.

    There aren't very many Mac Pro mid 2012 users, and numerous ML users who do not have or use a Mac Pro mid 2012. The vast majority of Mac Pro users are Mac Pro mid 2010 users and these machines do Not share the same firmware. (the Mac Pro mid 2012 firmware IS specific to that machine ONLY, so Yes, there IS something else involved with my three month old machine that is fully functional, it is unique)

    The techniques I specified Do work on a Mac Pro mid 2012, but curiously enough, not "always", so I included the Terminal method as well.

    Why doesn't it work "always"?

    Because it is an operating system bug that is modified by its Launcher refresh and alters its state depending on application installs and recent network connections.


    To be specific, my Repair Disk Permissions works very well if I have made no internet connection or network connections or application updates between clone backups.

    Therefore, symptoms WILL vary.


    Since there is No Permanent Fix, since MANY have experienced the problem, it IS an operating system bug.

    All the while.... one must ask self.... how many users actually use the "open with" option versus those who simply double click and may not be aware of the problem at all????


    Since it is only an ANNOYANCE it may be best to ignore it until Apple fixes it permanently.


    As far as YOUR experiences go, it may be useful to specify what machine you are using, and what cloning software you use. (if any)

    OR... do you intend to replace your entire operating system and applications with brand new installs WHEN (not if) your hard drive fails.

    If so, best set aside a couple days because you will be making many customer service calls because most new professional software requires online activation and will only allow you to activate once regardless if it is the same machine. (the problem with Time Machine is obvious, its just files)


    More importantly.... if you have not experienced this problem, "WE" all want to know why and why so many have had this problem. (actually an annoyance)

    For example, is your Time Machine backup GUID or APM?, is it Journaled?

    Do you use multiple internal hard drives?

    Can you use multiple internal non partitioned hard drives?

    What version of ML are you using?.... and on and on and on....

    (as far as Time machine users experiencing this problem, I have only seen one report, so it may be a fluke)


    Personally (as if it matters) I solved the problem permanently by switching to Snow Leopard.

    Since then.... I have not had one single problem with "duplicate open with" on a Mac Pro mid 2012 that did not self correct After The Clone Was Ejected. (proper operation should have "duplicate open with" until after the duplicate is ejected)


    Arguing what I or any other has or has not experienced first hand, does not make the experience vanish from reality.

    This is a technical forum where people share what they have experienced.... this is not a debating forum where people argue or assert psycho babble excrement.

    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?

    Seems that all evidence says NO.

    All majority consistent evidence involves those wise enough to make backup clones.

    Evidence clearly indicates that this Bug is dynamic, not static.

    Simply seek the parts of the OS that are dynamic to isolate the problem. (Launcher refresh)


    Did You Know....

    A similar refresh problem exists in your Network Settings?

    To "prove this" you will need to monitor the HARDWARE transceivers and ignore the User GUI.

    In short.... the GUI will indicate all hardware transceivers disabled, the hardware IS enabled upon wake up, and restart despite network settings and is Only Disabled when you Manually Refresh the Network Settings.

    A Refresh problem no different than the "duplicate open with" bug.

    A SERIOUS problem for those of us who are classified. (Apple concedes that this problem exists but has chosen to define it as Too Rare to repair since most customers want their network tranceivers automatically activated)

    I conceded that it was rare, but then asked the obvious.

    Why doesn't my GUI indicate that the transceivers have been automatically enabled?

    The GUI on ALL computers is supposed to ACCURATELY tell the User the state of the computer hardware and this has always been a fact.

    At that point my assigned case number was defined as "closed".


    Since this "duplicate open with" problem is not affecting function.... what will Apple's response be?

    Will it be.... not "everyone" has reported this problem?

  • R C-R Level 6 Level 6

    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.

  • TOAO Level 1 Level 1


    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.


    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.

  • R C-R Level 6 Level 6

    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.

  • ya_shin Level 1 Level 1

    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 ( 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.

  • R C-R Level 6 Level 6

    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.

  • TOAO Level 1 Level 1

    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.



    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?

  • TigerKR Level 1 Level 1

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


    killall Finder


    And now my problems are solved.

  • R C-R Level 6 Level 6

    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.

  • TOAO Level 1 Level 1

    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".

  • TOAO Level 1 Level 1

    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.

  • R C-R Level 6 Level 6

    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.

  • TOAO Level 1 Level 1


    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.

  • R C-R Level 6 Level 6

    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.

  • TOAO Level 1 Level 1

    That's great news!


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