Umount的时候注意了！（Moblin 内核 -- BICKLEY）

<script type="text/javascript"> document.body.oncopy = function() { if (window.clipboardData) { setTimeout(function() { var text = clipboardData.getData(&quot;text&quot;); if (text &amp;&amp; text.length&gt;300) { text = text + &quot;\r\n\n本文来自CSDN博客，转载请标明出处：&quot; + location.href; clipboardData.setData(&quot;text&quot;, text); } }, 100); } } </script><script type="text/javascript">function StorePage(){d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://www.365key.com/storeit.aspx?t='+escape(d.title)+'&amp;u='+escape(d.location.href)+'&amp;c='+escape(t),'keyit','scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes'));keyit.focus();}</script>

Bickley是一个元数据管理 API 和框架，由三个主要部分组成：

l  L ibkozo ——  Kozo 是围绕 TDB 库的数据库抽象。

l  L ibbickley ——  L ibbickley是一个客户端 API ，允许客户端通过较高级别接口访问元数据。

l  D aemons —— 有两个 daemon ，分别用于从文件和其他来源提取元数据和对这些元数据编制索引。

 

L ibbickley

L ibbickley以列举项的形式将数据呈现给客户端。目前共有三类列举项，分别代表音频、图像和视频项。对于与这些类型相关的元数据，列举项还包含一些文件相关的元数据和一些自定义元数据，比如播放次数、排名、标签。

通过使用 L ibbickley，客户端不必了解 libkozo 是如何将数据保存在数据库中的，而且对数据的所有操作都应该通过 L ibbickley完成。

 

Daemon

组成Bickley 元数据系统的两个 daemon 是 bkl-orbiter 和bkl-investigator 。 bkl-orbiter 始终处于运行状态，可以跟踪各种来源，从而监视来源上需要为其编制索引的文件。当它发现需要提取的内容时，bkl-investigator 就会启动并扫描随后要发送给 orbiter 的元数据文件。

目前， bkl-orbiter 能够监视的来源有：

l  GConf —— 表示本地文件系统。

l  可移除的媒体 —— 表示CD/DVD 和可移除的存储设备。

l  UPnP —— 表示局域网上基于 UPnP 的媒体服务器。

GConf来源可以监视键 /apps/bickley/watched_uris 并对在该键中找到的任意 uri 编制索引。

当新的来源可用时， bkl-orbiter 还会发出D-Bus 信号，而 L ibbickley可以将此信号通知客户端应用程序。

 

元数据的存储位置

元数据存储在设备的文件系统中。对于本地文件系统，数据库存储在 ~/.kozo/databases/local-media 中。

l  对于UPnP ，元数据也存储在 ~/.kozo/databases 中，而数据库文件名就是UPnP 设备 UDN 的 MD5 和。

l  对于可移除的媒体，如果该媒体是可写的，那么元数据存储在 $(mount_point)/.kozo/databases 中，否则也存储在 ~/.kozo/databases 中，数据库文件名是挂载点的MD5 和。

 

使用lsof /media/disk查看发现 bkl-orbiter 在使用$(mount_point)/.kozo/databases

那么，直接用UMOUNT不行了。可以使用gnome-umount。