2.0.0 can't be run from outside /Applications

[Calum Benson]

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.

[bird]

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

[aquarius]

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

[Calum Benson]

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.

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

[Calum Benson]

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.

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

[Timothy Hatcher]

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.

[Martin Häcker]

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.

[Frank Mehnert]

develper tool != virtual machine

[Calum Benson]

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

[Matthew Ryan]

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.

[Technologov]

Bug #2648 looks like a duplicate of this one.

-Technologov

[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

[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)

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

[Frank Mehnert]

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.