VirtualBox

Ticket #2054 (closed defect: wontfix)

Opened 6 years ago

Last modified 12 months ago

2.0.0 can't be run from outside /Applications

Reported by: calum Owned by:
Priority: minor Component: installer
Version: VirtualBox 2.0.0 Keywords:
Cc: Guest type: other
Host type: Mac OS X

Description (last modified by frank) (diff)

VirtualBox 2.0 can't be run from anywhere other than the /Applications folder. This is a regression from 1.6, and poor behaviour for any OS X app.

Perhaps this restriction is to simplify the new update checks, but plenty of other Mac applications handle this properly... and even the ones that don't, still allow you to run the application from outside /Applications: they just install any updates into /Applications, rather than correctly over-writing the previous version.

Change History

comment:1 follow-up: ↓ 15 Changed 6 years ago by bird

  • Status changed from new to closed
  • Resolution set to wontfix

Sorry, that's no longer possible mainly due to restriction in the dynamic linker (dyld).

comment:2 Changed 6 years ago by aquarius

  • Status changed from closed to reopened
  • Resolution wontfix deleted

(just reopened to draw attention to side note)

Side Note:

In the 2.0 Mac installer there is an option to choose not only a second harddrive but also to change the installation path.

I did not try this, but his would

a) remedy the issue or b) be another minor defect because it's misleading

In any case, I would be glad to see some clear and highly visible notice in the installer reading

a) here is the only chance to make your choice or b) VirtualBox will be installed in Apps (and no choice)

Should I open a new minor ticket for this?

comment:3 Changed 6 years ago by calum

The button to change the "Install Location" only lets you change the path if the application supports it. Otherwise, it just takes you back to the step where you choose which hard disk to install onto, and that's what happens with VirtualBox.

comment:4 Changed 6 years ago by aquarius

calum: This behaviour can not be changed? (I never programmed/configured a Mac installer)

Anyway it comes down to a highly visible note so that users don't even try to change the installation because that seems common with mac users.

comment:5 Changed 6 years ago by calum

I've never written an installer either, but yes, AFAIK the 'choose path' option is something that can be easily turned on in the (Leopard) installer.

However, I presume that turning on this option won't magically make VirtualBox work when it's installed into a location other than /Applications. That would still have to be fixed first.

comment:6 Changed 6 years ago by aquarius

calum, look at the first change of the ticket by bird:
Sun classified your original claim a wontfix. I assume because they use some resticted dynamic linking in connection with some security/hardening considerations. It seems that in their eyes this is more important than your/our wish to freely move the application. Although the developers could explain the implications of their choice better, I'm afraid we have to accept them in the first place (or start a broad Mac User discussion on what users prefer).

My suggestion then boils down to showing a highly visible note about the only place to install the app plus having no fruitless dialogs in the installer pretending the user had a choice.

comment:7 Changed 6 years ago by xenon

This bug recently bit me since I organize all of my applications into sub-folders. Now VirtualBox is the only one I can't organize, so it is sticking out like a sore thumb. This is very much not like any other Mac application.

comment:8 Changed 5 years ago by dwt

This can be worked around by making a symbolik link to the real application in the /Application/ Folder and then making that link invisible.

No real sollution, but at least it works and your application folder is a lot more tidy.

As to the Developers: Apple is able to run its developer tools from anywhere you choose to move that folder - it should be very easy for you to do the same.

comment:9 Changed 5 years ago by frank

develper tool != virtual machine

comment:10 Changed 5 years ago by calum

True, but VMware Fusion and Parallels run quite happily outside of /Applications too, so there's nothing inherent in virtual machine technology that makes this impossible. Just an architectural flaw with this *particular* virtual machine technology, presumably...

comment:11 Changed 5 years ago by Ensoniq

Just agreeing with some others here...there are very few Mac OS X applications that cannot be run from a sub-folder. Those that cannot are usually fixed by pointing out the flaw to the developer, just as was done here.

If the developers insist that it cannot be done with 2.0, while it worked fine with the 1.x versions, then it would be nice if they believed in our intelligence and posted the specific reasons why it cannot be done now.

comment:12 Changed 4 years ago by Technologov

Bug #2648 looks like a duplicate of this one.

-Technologov

comment:13 Changed 4 years ago by Technologov

Technologov, while not a Mac expert (yet), agrees with other users, that if VirtualBox 1.x and other virtualizers can work from any folder, so must VirtualBox 2.x and 3.x.

-Technologov

comment:14 Changed 4 years ago by cryptyk

In supR3HardenedGetFullExePath, shouldn't it be using _NSGetExecutablePath instead of _dyld_get_image_name(0)? I'm not on a dev machine right now, but I think that would return the correct path to the executable (although it isn't guaranteed to be absolute)

comment:15 in reply to: ↑ 1 Changed 12 months ago by Frungi

I don’t understand the difficulty here. I don’t think there’s any excuse for a self-contained app to break by just being put in a different folder. Is there some reason that VirtualBox MUST use hard-coded absolute paths (/Applications/VirtualBox.app/Contents/…) and cannot use relative paths (../../)? I urge the developers to look into this.

Do the Windows and Linux versions show the same behavior when moving the installed file/folder? I haven’t used it on those systems.

comment:16 Changed 12 months ago by frank

  • Status changed from reopened to closed
  • Resolution set to wontfix
  • Description modified (diff)

Yes, there is a reason for hard-coded absolute paths and bird (one of the VirtualBox developers) already said that this is a restriction of the dynamic linker. VirtualBox uses suid root stubs for starting the actual application for security reasons and this is not possible with relative paths. The same restriction applies to VirtualBox on Linux.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use