Desktop search

With a desktop search, searching an entire computer, or rather its mass memory ( such as hard disk drives) respectively. This contrasts with the Web search, in which the entire Internet or any part thereof be searched. While for the latter search engines like Google, Bing or Yahoo can be used, special desktop search programs can be used for fast browsing of computers using various content. It is read by the application usually searches the entire database of the computer, filtered, indexed and referenced in a database. The program interface then accesses this database, making a return to the results in real time is possible almost, and finding very agility over traditional search methods, such as the file search in Windows or place under UNIX derivatives wins. Desktop search systems are also characterized by a very high precision from, because they filter the searched content depending on the file type and assign this information to also mutatis mutandis.

" Classic " search and desktop search

Precursor and pioneer of today's desktop search systems is the UNIX tool locate. This classic command-line program scans an index of the file system that is updated periodically by a cron job. Originally supported locate only the search for the file name. Over time, however, it was extended more and more, among other things, regular expressions. Even today (2011) it is an important tool. However, compared to modern desktop Search locate has one major drawback: It refers purely on file names, not their interrelationships, file types, or content. Reacts also locate not in real time to changes in the file system, but only after updating the file system index. Thus the returned by locate content may be out of date.

More common was in the past, the method to search for each query the hard disk again. To use this method comes about under Unixes in place, with Windows Search, or the Finder search in Mac OS. The search order generates a very high system load, depending on the search of each file name, sometimes the contents of each file must be compared with the specified search pattern. This high burden, especially for fixed source of independent computers, as well as the costs borne waiting time are hardly acceptable under conditions of use, as the search is mostly anyway limited to a defined group of files ( for example, all IRC protocols). In addition, this type of search is quite unspecific and either not at all or only with beginner -border knowledge (for example, the obvious combination of grep with find ) extensible.

Therefore desktop search systems have been developed. Automatically index a given set of files ( for example, all files in the home directory of each user or all readable in the file system for the user files), filter, analyze and sort their contents by their type, (for example, OpenDocument, PDF, image files, e mails, etc. ) and place the results in their index. About modified and newly created files, the index will be informed either of the programs themselves or by monitoring the file system ( for example, via inotify ).

By the user, the index can then be interviewed using integrated into programs or individual programs offered functions. Internal access is often done by means of a uniform, standardized database interface (eg SQL), which is partly made ​​available to the user directly. This highly specifiable (for example, regular expressions ) and fast ( apparently almost instantaneously running ) search represents a significant productivity and time savings dar. In the normal file dialogs integrated, can be found and selected on the basis of search results as quickly and efficiently files without to spend a long time navigating the file system.

Types of Desktop Search

Recent examples of the latter method are approximately:

• Search functions in KDE, which have become more and more since the development of version 4.0. There numerous search tools and interfaces for KDE have been developed which tend to cooperate better and better. An example of this is the close linkage of catapult with Kat and Beagle, and applications such as Amarok.
• Search capabilities in BeOS / Zeta, where done by associative file management both an abstraction, as well as convenient access.

Opportunities and threats

The central storage and mapping of the data of a computer allows for a much more intuitive and finding new ways of dealing with the data. However, it also poses some risks: The data are stored centrally, according to the wishes of some providers (eg Google) even centrally on servers in the Internet. This provides both abuse potential for crackers could exploit vulnerabilities in software to gain access to sensitive data, and on the part of governments, for which such a central data pool is a tempting opportunity for solving crimes, but also to preventive monitoring individual can be abused. Even industrial espionage can be simplified.

Operation

Basis of all these systems is the use of a database to store the meta- information, and the provision of appropriate interfaces / APIs for accessing this database. The processing of the information in this database, the user can then take place in different ways.

Representation via search programs

This method is computationally simple and robust saw. The search is done on your own user programs. There are no serious interference with the functioning of the underlying operating system necessary, but consequently lacks the intuitive integration, such as in file dialogs and the like.

Examples of this method are about Superior Search, Google Desktop Search, regain, DocFetcher xfriend, Windows Search, Copernic Desktop Search, Yahoo Desktop Search, Exalead desktop free or Beagle ( in its basic equipment ).

Integration into the file system layer (associative file management )

Latest developments tend towards an associative file management, the presentation of the Dateisystem-Schicht/das virtual file system (VFS ) of the operating systems. This can be done in various ways, all of which can have certain advantages and disadvantages. Such integration enables a particularly intuitive, since the user does not need to distinguish between found and hierarchical data stored in the ideal case.

An already matured such a development is also located in the BeOS -based operating systems, where it was placed on the file system BFS on the VFS of the operating system. It has been a very fast, user- friendly desktop search from any application, and has proved to be extremely stable.

The large free desktop environments KDE and GNOME, but also the Finder in Apple Mac OS X provide for a long time about their virtual file system similar services. The referencing of files based on their meta - information seems to be one important way in the future, and could, especially for inexperienced users, lead to a significant relief in dealing with computers. The integration of these functions on such a VFS offers numerous advantages for developers, but it also requires that applications that want to use these functions directly, not allowed to directly access the file system, but to do so through the appropriate system libraries on the use of the VFS. However, there are now approaches that integrate these VFS systems directly in the file system under Linux for example via the FUSE filesystem.

Microsoft worked occasionally on WinFS, a SQL -based file system layer that would have been ideal for a system-wide desktop search. Such a deep integration into the operating system of Windows - VFS, such as Microsoft had intended that, but led to unexpected problems. Microsoft has announced in June 2006, a setting of the project.

Search work functioned similarly, but went some potential problems out of the way, by representing its data in the form of a network drive. There are now no longer the company.