GNOME Bugzilla – Bug 321512
beagle should be able to index removable drives
Last modified: 2018-07-03 09:55:09 UTC
Nowadays buying a huge USB hard drive is almost cheaper and much more practical than storing data on DVDs. This is specially true when you have a laptop and can't and an internal hard drive. Unfortunately, beagle can not index these disks: one they are removed, /whatever-mounting-point is empty and the files are removed from beagle index. That should be a great feature if one could specify with gnome-settings that such repertory is a mouting point for a removable drive.
This might be easier to do with shell scripts than in beagle. Write a smart shell script that uses hal/hotplug to determine when a usb drive is inserted, find out which (if you have multiple USB drives) one has been inserted and run beagle-build-index on that with the indexpath determined by which usb key has been inserted. Everytime you run beagle-build-index, it will only update the new/changed files.
Nowadays, Beagle can be used to replace Nautilus' search. If it does, it has to be able to search for files anywhere on your computer. Thus, it is very important for beagle to be able to automatically index newly inserted CD-ROMs or USB drives. Users shouldn't have to worry about it and whrite scripts.
*** Bug 368189 has been marked as a duplicate of this bug. ***
This is definatly something we should start to look at again in the near future, probably after Joe gets his unified indexies branch merged, but to foster discussion, we have a few different routes we could take with reguards to actual implementation. 1) HAL/Dbus solution: Were already considering adding dbus back in, its a big dependency (Hal and Dbus) but its exactly what hal was written to do, so it shouldn't be too hard.(ignoring the api inconsistancies) 2) Beagle-Settings: We have users specify drives they want indexed, and just wait until something like mtab says they have been mounted, at which point we index, much sloppier and hacky, I'd recommend #1.
We definitely want to go the HAL route here.
Incorporating the needed dbus/hal stuff into the current build system will be a pain (always is a pain when you have to add a dir in CVS). Otherwise just using hal to detect the mounting and unmounting of drives is pretty easy. My question is, what is our policy? I have a simple HelloHDFromHalWorld.cs working (using the banshee build system to mooch dbus/hal) but we need to decide things like, are we just building a static index every time a drive is attached? are we just adding the drive as a root to the fsq?
Please. I dont like smart systems. In my view, make it two tiered, 1) BuildRemovableIndex -> which creates/updates a special static index and informs beagle about it through conf. This way user can later control which removable indexes it want to enable/disable. And indexes can be dragged along if desired. Removable media is still not widely used as a filesystem with constant read-write - they are mostly for read-only storage media. No need to watch them. All paths are stored wrt to the mount point. 2) Have Hal scripts (distributions always love to tweak media autorun settings) to run BuildRemovableIndex whenever media is inserted. Hal or whatever can be used to tag the RemovableIndex with whatever tag the user/distribution thinks useful. Hal ids are not always useful media identifiers. 3) When presenting a hit from removable media, if the path doesnt exist, ask the user to insert the media (using the friendly media tag used during indexing) or merely inform that the file was present in the currently unavailable media (like you index all your mp3 CDS and use beagle to find any mp3 file in those CDs).
*** Bug 418081 has been marked as a duplicate of this bug. ***
Bug 418081, which I just marked as a dup, has the basic outline of how I would also implement this. We can't automatically store the index on the device (because the index might be too big, writes to flash are expensive, etc.) but it could be a configurable option. I'm not 100% sure on whether indexes for removable devices should be systemwide or per-user. That would influence the design quite a bit.
(In reply to comment #9) > I'm not 100% sure on whether indexes for removable devices should be systemwide > or per-user. That would influence the design quite a bit. Part of that comes back to the old HAL problem of "who owns this device?". In this case, the problem is the decisions regarding whether to index or not, and whether to store the data on the device or not. OTOH, at least there shouldn't be any other choices beyond that, which possibly simplifies the problem. I guess one option would be to make the indexer itself systemwide, but the choices at both system and user level. System level can specify defaults (and possible lockdown of options), and the user(s) can than also express their preferences, assuming they have sufficient permissions (system lockdown, file-level permissions for reading/writing in the indexing/writing of indexes options). This transitions the "whether to index" problem to a "do we include this index in beagle's search list?" - one or more stakeholders (system, user(s)) requesting an index to be included makes indexing happen. If, for example, system requests all indexes, and the user wants to exclude them, then indexing still happens but the user doesn't see the items in beagle. Storage of indexes could be done in the same way - if anyone wants it (who has enough permissions) then do it. In effect, an index is just another file to be stored - if the user can write files to a device, then they should be allowed to make decisions about index storage for that device. In the case of index storage, it should possibly be made clear of what is the end result of a user choice i.e. if indexes are switched on at system level, but the user shouldn't be able to switch it off totally without superuser permissions.
Just wanted to point out a couple of advantages of storing the index on the disk itself (the use case I have in mind is a laptop user having little free space in the home and a big external hard disk) 1) One can save space on the laptop (indices tend to have quite a relevant size) 2) One obtains consistent results: when the hard disk is not plugged in I should not find the files it contains, since they are not available to me anyway 3) One can use the same index on different computers, without the need to recreate it each time in different locations. Is there any progress on this issue?
Beagle is not under active development anymore and had its last code changes in early 2011. Its codebase has been archived (see bug 796735): https://gitlab.gnome.org/Archive/beagle/commits/master "tracker" is an available alternative. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.