Opened 12 years ago

Closed 5 years ago

#1629 closed bug (fixed)

Apps on non-boot partition are ignored

Reported by: humdinger Owned by: axeld
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


This is vmware, hrev22943.

I have several apps on another image that is mounted at bootup. One of the apps is the editor Pe. When I right-click a text file the submenu of "Open with..." only offers "StyledEdit" although "Text" is one of Pe's supported filetypes. When clicking the "Open with..." also only capable apps from the boot partition are displayed. Looks like non-boot partitions aren't scanned for applications at all.

Change History (14)

comment:1 Changed 12 years ago by axeld

The other applications must be on a BFS volume, and you need to have started these apps to become known in the MIME type system. Since this is a Tracker feature that works fine on BeOS, it should also work just like that on Haiku. Can you confirm the problem goes away if you follow the rules mentioned above?

comment:2 Changed 12 years ago by humdinger

The other image is also a BFS volume and all the apps have been started once already.

Also, opening the FileType Add-on for a text file these apps ARE listed in the Preferred Application drop-down. Besides "pe" there's also Gobe Productive and NetPositive; all residing on the non-boot image. Only the "Open with..." menu/window won't show those apps.

comment:3 Changed 12 years ago by bonefish

Does this non-boot volume have a BEOS:APP_SIG index (and if so, was it created before the concerned apps were installed)?

comment:4 Changed 12 years ago by humdinger

Nope, there was no BEOS:APP_SIG index on that image. I just did a mkindex -t string BEOS:APP_SIG and duplicated the whole apps folder, deleted the old apps folder and launched Pe, Net+ and Gobe. Still, there are none of the apps that are on that non-boot image in the "Open with..." submenu/window. (Though, as I said, they are listed in the FileType Add-On). Also did a reboot.

comment:5 in reply to:  4 Changed 12 years ago by bonefish


query -a BEOS:APP_SIG=application/

turn up Pe's executable path?


open application/

open Pe?

comment:6 Changed 12 years ago by humdinger

Affirmative. Both lines turn up what they should.

comment:7 Changed 12 years ago by bonefish

Component: Servers/registrar- Applications/Tracker
Owner: changed from bonefish to axeld

At a first look Tracker doesn't even seem to use BRoster functionality to fill the "Open With" menu (only for getting the preferred app). It queries for the supporting apps by hand (getting their signatures should work as they show up correctly in FileTypes). So I guess it's safe to assume that this is either a Tracker bug or BFS has a problem with the more complex queries Tracker uses. Let's blame Tracker first...

comment:8 Changed 11 years ago by RandomInsano

I don't have this problem on Haiku. I have Max 5 installed on a second partition that is mounted on boot and both versions of Pe and other applications are available in the 'open with' menu. Is this still a reproducible bug?

comment:9 Changed 11 years ago by humdinger

It's still here. At least on vmware.

Once an application was started from that non-boot image, it shows up in the FileType Add-On of that file. But not in the "Open with" submenu/panel.

Plus: Before I've started a graphics app from non-boot, the "Open with" submenu/panel for a screenshot showed Firefox, WonderBrush | [checked] Showimage | DiskProbe, FileTypes, Tracker. After I started Becasso from the non-boot image, I only get Firefox in the submenu/panel.

Restarting doesn't help. Gots to reinstall a new haiku-image.

comment:10 Changed 11 years ago by humdinger

Just tried with a native hrev28382 (?, around that revision...). Same results with an old BFS backup CD from 2001.

comment:11 Changed 9 years ago by mmadia

Does this still occur on R1 / Alpha 2 or on trunk?

comment:12 Changed 9 years ago by humdinger

Since Pe is in my image by default now, I installed ArtPaint to the non-boot partition and did the tests with a PNG.
On my native install (hrev37437) it does work as expected, at least, after I once invoked the FileType add-on on the binary. I guess starting the app once would do the same. After that ArtPaint appears in the "Open with" menu.

I also tried a current revision (hrev37830?) in VirtualBox. Here the original problem persists. Whatever I do, even after launching ArtPaint once, the entry never appears in the "Open with" menu.

Back when I originally filed the ticket I didn't have a native install... I leave it to the devs if the current behaviour is "good enough".

comment:13 Changed 5 years ago by luroh

hrev47918, gcc2 (jam -q haiku-vmware-image, i.e. no Pe installed on the system disk), VirtualBox. I am unable to repeat the original problem.

comment:14 Changed 5 years ago by humdinger

Resolution: fixed
Status: newclosed

Can't reproduce with a native install either. Thanks for checking! Closing as fixed.

Note: See TracTickets for help on using tickets.