<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<herd>no-herd</herd>
<maintainer>
 <email>vapier@gentoo.org</email>
 <name>Mike Frysinger</name>
</maintainer>
<longdescription>
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.
</longdescription>
</pkgmetadata>