no-herd vapier@gentoo.org Mike Frysinger Efsd, the Enlightenment File System Daemon, is a daemon that provides commonly needed file system functionality to one or more clients. It comes as a library that clients (like e17) use, sending commands to the daemon, which asynchronously reports back the outcome of the commands when their execution is finished. Efsd therefore decouples the client 100% from any file system related tasks (which means that you will for example not see a GUI application hang, assuming it is coded sanely), specifically, it does the following: * Implements basic file operations (ls, cp, rm, ln -s, stat ...), with a flexible option passing system to provide equivalents of recursive processing, force options, alphabetical sorting etc. * Reports file change events, currently using FAM, so that a client gets instant reports when files are removed, deleted, renamed etc. I've looked at BSD's kqueue mechanism and Linux 2.4's dnotify, and it seems Rusty and his friends at SGI are planning on adding direct support for these to FAM (well, at least for the kqueue mechanism). * Delivers file type requests to the clients, i.e. clients ask for a file's type, and Efsd does its best to come up with a good reply. Efsd extends the concept of MIME types for data type specification to more than two levels (e.g. "image/gif/89a"), to allow arbitrary levels of granularity. A three-tiered approach is used to determine the file type, not unlike the way the Unix file(1) command works. These three levels are tried in order of decreasing reliability: o First, the result of stat() and statfs() calls are checked to see if a file is a directory, socket, fifo etc. In that case, a reply like "ext2/directory" is reported. o If that didn't help, file magic is used to check for detailed file characteristics. A database based on a magic file (check man magic for details) is used to put together a detailed file type. Efsd can therefore deliver file types with the same high level of granularity that file(1) provides, for example, asking for an mp3's file type results in a reply as detailed as audio/mp3/160-kbit-s/44-1-khz/jstereo. It is up to the client to make as much use of the information as necessary. o If that also didn't help, classic file name pattern matching is used, e.g. anything *.foo is a foobar file etc. File type lookups are cached in order to increase performance. With a client that uses Efsd, no user will ever click on what seems to be an mp3, accidentally executing a malicious script. * Handles setting and retrieval of arbitrary metadata, e.g. like storing/querying for file icons, icon coordinates etc. The type of data to be stored/retrieved is entirely up to the clients. * Can monitor metadata and sent events to the client when metadata entries change. * Caches results of stat() calls to increase performance. FAM is used to let Efsd know internally when a file has changed, so that cached stats can be updated. * Supports multiple clients. Besides the simpler case of regular fs commands, Efsd implements filechange event (de-)multiplexing, i.e. file monitoring requests are use-counted and resulting events are forwarded to the appropriate clients which requested the monitoring. efsdsh, an interactive command line interface to libefsd is a nifty little tool for testing things like these ... * Multi-threaded implementation, as long as POSIX threads (pthreads) are available on a system.