I have something to add regarding this new addition to the SoC ideas page: "4. Near-real-time enhancements for locate and updatedb"
Once implemented with the "extended meta-data support", it can make GNU Findutils a command line counterpart of Beagle and Tracker. Instead of directly interfacing with the kernel's inotify sub-system, we can also have a look at libinotifytools which is a part of inotify-tools (http://inotify-tools.sourceforge.net/), and for the Hurd we can make use of translators. However since my knowledge of Hurd is limited, I will limit myself to GNU/Linux systems. Here is a brief outline: a. Depending on the availability of a meta-data extraction library, configure Findutils during the build stage to enable/disable the ability to read the attributes which are unique to a particular type of file. This should affect all the components-- find, locate, updatedb, etc.. b. Have a separate updatedb daemon, depending on whether inotify is available in the running kernel, apart from the conventional updatedb executable. The daemon should make use of the inotify feature of the kernel to keep the database updated. An update operation should be invoked by the events generated by the inotify subsystem and not involve processing the names or meta-data of files in the database that have not been changed. Whether this daemon will store the meta-data is also decided as in (a). c. Make sure that both updatedb and updatedb daemon are not running at the same time to prevent database corruption. d. Try to keep all these features as transparent as possible to users of find and locate to prevent breaking existing shell scripts. This means that the default behaviour should not change, and ability to look at the newly added extra meta-data should only be enabled via flags. What do you think? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu _______________________________________________ Bug-findutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-findutils
