[Tracker] shows packagefs volumes in Desktop menu

[jessicah]

When you right click on the Desktop and navigate the folder hierarchy, the packagefs volumes are listed in addition to normal volumes.

[jessicah]

diver asked me to check with DiskUsage as well, and these volumes no longer show in DiskUsage either, fyi :)

[bonefish]

Well, that flag was ​introduced intentionally. I guess one way or the other special handling will be needed in Tracker (and maybe other apps).

[jessicah]

The behaviour without the persistent flag seems the most correct, and generates the desired behaviour in apps like Tracker & DiskUsage.

Queries should work on any volume that marks itself queryable IMO. The fact Tracker ignores certain queryable volumes just because they're not persistent seems like the real bug here. However, I don't know the history of OpenTracker and if it was always like that, or changed to address some other unforeseen issue... but I'll press on with a patch to address that and see what happens :)

[bonefish]

Replying to jessicah:

The behaviour without the persistent flag seems the most correct, and generates the desired behaviour in apps like Tracker & DiskUsage.

According to the BeBook:

B_FS_IS_PERSISTENT. Data written to the device remains even while the device is off.

That applies to a packagefs volume, so, strictly speaking, setting the flag is correct.

Queries should work on any volume that marks itself queryable IMO. The fact Tracker ignores certain queryable volumes just because they're not persistent seems like the real bug here.

Well, the heuristic certainly isn't very good. But I also don't think that just because a FS does support queries it generally makes sense to present that option to the user. Maybe we need a new flag (or multiple flags) to more precisely specify the purpose of the FS. Or maybe we simply need to do special casing in the various concerned apps depending on the FS type.

[jessicah]

Replying to bonefish:

Replying to jessicah:

The behaviour without the persistent flag seems the most correct, and generates the desired behaviour in apps like Tracker & DiskUsage.

According to the BeBook:

B_FS_IS_PERSISTENT. Data written to the device remains even while the device is off.

That applies to a packagefs volume, so, strictly speaking, setting the flag is correct.

Okay, I couldn't find that in the BeBook... =/ The only part I did find was:

If the volume's storage is persistent (as opposed to the ephemeral storage you get with virtual file systems).

Given that packagefs is both virtual and read-only, it seemed like my interpretation was correct. And as the fix you mentioned seemed to only be due to queries not working in Tracker, I still thinking fixing Tracker is the right way to go.

[bonefish]

ISO FS and UDF are also read-only, so, obviously, this property is orthogonal to B_FS_IS_PERSISTENT. One could even argue whether packagefs is virtual -- its storage back-end (the packages directory) is very real and persistent (much like a mounted ISO image file).

Anyway, giving B_FS_IS_PERSISTENT a meaningful interpretation is one issue. The other is that regardless of what is decided for packagefs, we'll probably still need special handling for it (i.e. packagefs) in those applications:

• In the Find dialog IMO the preferable behavior is not to list the packagefs volumes in the volume menu, but automatically include them in the search when the parent volume is selected.
• In DiskUsage it doesn't make much sense to include the virtual packagefs directories when the boot volume is selected, though it does make sense to include the shine-through directories. The inverse view might also be interesting, so one can examine what in the packages takes so much space.

[axeld]

One solution that comes to mind is to have a look at the mount points, and consider mount points within a volume as part of that volume for queries, and Desktop view. Alternatively, this behavior could be triggered by an extra flag, so that not all file systems mounted within another would share this behavior (although I'm not sure this is really needed).

BVolumeRoster/BVolume could get convenience methods to get those, so that each application where this makes sense could use them (like /bin/query, etc.).

[jessicah]

I still think removing the B_FS_IS_PERSISTENT flag is the right way to go. The arguments against it really don't hold that much water, and would introduce a series of needless and ultimately ugly hacks.

Another case to support removing the B_FS_IS_PERSISTENT flag is if you boot Haiku from a different volume, the entire directory hierarchy when booted from the previous volume doesn't exist any more.

And as for querying, Axel's idea of including mount points within a volume (if they can be queried, such as packagefs is) would properly resolve the issue that the change mentioned in comment:3 was intended to fix, and gives behaviour that is also logical.

Any hints on where to look for adding support for passing a query on to nested volumes?

[bonefish]

Replying to jessicah:

I still think removing the B_FS_IS_PERSISTENT flag is the right way to go. The arguments against it really don't hold that much water, and would introduce a series of needless and ultimately ugly hacks.

Another case to support removing the B_FS_IS_PERSISTENT flag is if you boot Haiku from a different volume, the entire directory hierarchy when booted from the previous volume doesn't exist any more.

The same could be said for a BFS image. If you don't mount it, its contents isn't visible. Or the other way around: If you mount the packagefs on another volume, everything is there again. So packagefs could be considered virtual but it certainly is not volatile. A dedicated RAM FS volume would definitely be both virtual and volatile, but one would still want to have it appear as a volume in Tracker. OTOH, if we implemented a life CD such that RAM FS instances were mounted where writable directories are expected (settings, var, etc.), we would not want them to appear in Tracker as separate volumes.

To sum it up: The way Tracker uses the B_FS_IS_PERSISTENT flag doesn't have much to do with the actual kind of the file system and one may even want different instances of the same file system behave differently.

Anyway, I'm not opposed to (re-)defining the semantics of B_FS_IS_PERSISTENT as "shall appear as a volume in Tracker" and removing the flag in packagefs.

And as for querying, Axel's idea of including mount points within a volume (if they can be queried, such as packagefs is) would properly resolve the issue that the change mentioned in comment:3 was intended to fix, and gives behaviour that is also logical.

Any hints on where to look for adding support for passing a query on to nested volumes?

I'm not a Tracker expert, but the QueryEntryListCollection constructor (in QueryPoseView.cpp) looks like the place.