Tài liệu Database File System: An Alternative to Hierarchy Based File Systems docx

Database File System
An Alternative to Hierarchy Based File Systems
O. Gorter
University of Twente
August 
Database File System — An Alternative to Hierarchy Based File Systems
Author: O. Gorter
Supervisors: H. Scholten, B. van Dijk, P.G. Jansen
Copyright
C
2003, 2004 O. Gorter
University of Twente, Computer Sciences
Enschede, the Netherlands

Database File System
O. Gorter III
Abstract
——
Over 30 years people worked with hierarchical file systems; file systems based on directories and files.
These file systems have proven their use, but today, with gigabytes of storage and millions of files,
managing files with directories is becoming increasingly difficult. This research presents an alternative to
hierarchy based file systems. At the basis of this system is a unified approach to all properties of a file.
Combining this approach with a drag and drop user interface creates an alternative that is as usable as
directories, while in the mean time going well beyond the expressive powers found in hierarchy based file
systems. The end result is a file system which makes working with files a lot easier on the user. Emphasis
of this s ystems lies at the user and not the operating system, therefor files like shared libraries do not
show up in this system, these should be stored by other means. The implementation is an abstraction
layer above a hierarchy based file system and the two work together in such a way that a high level of
backwards compatibility is achieved, not rendering current programs useless. This setup has been tested
on users and the results indicate that this system is a very valid alternative to hierarchical file systems.
Database File System

O. Gorter IV
Foreword
——
This document is my graduation report for the University of Twente and is all about the Database File System
(dbfs); my graduation project. Because this document is mainly written for the University some content might
not be relevant to all readers. For those only interested in what the dbfs is, I recommend reading chapters
“Introduction” and “Database File System – Overview”.
The document assumes the reader has a fair knowledge of current computer systems and related terms. As
a reference, most terms are explained in the chapter “List of Used Terms and Abbreviations”, related
research and documents are in chapter “References”.
All of the research in this document is done from a user and user interface point of view. This is different from
most research on file systems, and explains why compared to these writings, seemingly important information
is left out, while almost trivial points are discussed in depth.
For those who obtained this document digitally, it is available in two versions, one optimized for screen reading
and one optimized for print (dbfs-screen.pdf and dbfs-paper.pdf resp.). The screen version has a 4 : 3
layout with a slightly larger font and is definitely recommended when reading from a monitor.
Thanks
For all their advice, support, help and faith, I would like to thank Hans Scholten; Betsy van Dijk; Pierre Jansen;
all the others on the dies group; my flatmates; and my family.
Also a special thanks goes out to all the usability testers, whom I will only mention by first name, but you know
who you are.
Database File System Foreword
O. Gorter V
Albert
Bas
Coen
Edgar
Epco
Erwin
Gerben

Harry
Igor
Ivo
Janneke
Joris
Jeshua
Marc
Martin
Stefan
Tim
Rutger
Database File System
O. Gorter VI
Contents
——
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV
 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Relevance 
 Hierachy Based File Systems – Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Properties of Hierarchy Based File Systems 
 Database File System – Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Relevance 
. Categorisation 
 Database File System – Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. User Interaction 
 Database File System – Internals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Server 
. Client 
. Graphical User Interface 

 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
Database File System Contents
O. Gorter VII
. Objective 
. Method 
. Results 
 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Future Work and Recommendations 
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
Related Work 
Related Software 
Other References 
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
List of Used Terms and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
A Assignment – Database File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
B Dutch Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
C Test 1 – Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
D Test 2 – Arrange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
E Interview 1 – Email Normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
F Interview 1 – Email Dbfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
G Interview 2 – Arrange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
H DBFS Source File Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
Database File System
O. Gorter 
Introduction
—1—
File access and file management is something we do on our pcs every day; lots of computer time is spend
browsing our directories and opening and saving files, or worse, finding files. The basis for this system was laid
down over 30 years ago, and since graphical user interfaces became main-stream not much has changed. Yet
computer hardware has become increasingly more powerful and limitations that existed are no longer there. Still

the biggest change in our file interface is preview (thumbnail) rendering in the file manager.
A new file system can introduce better metaphors on working with files and can make use of advanced gui
techniques not available when hierarchical file systems came into use. It can bring the focus of the file system
to the user, instead of the computer, and in doing so change how we think about files and the whole computer.
It can be an enabler for a new and more up-to-date user-oriented computer interface.
And this is exactly what this research is about, trying to bring file management to the user. It does so by providing
a search based file interface, based on file meta-data, and it introduces keywords in favor off directories. Being
user oriented means only storing documents and not system files like shared libraries. Where documents are all
files the user is interested in, this can be a msword document, but also images, music and more.
Because the systems searches and modifies meta-data, all meta-data can be treated equally, meaning that
security, ownership and sharing are just as easy to manipulate as the file-name or keywords. And without
directories the systems does away with locations, instead it can categorize documents in a more powerful way.
Without locations on a file system, we can have applications that just save everything you do. The save button
can be completely removed from every interface element of the computer, doing away with the dualistic nature
Database File System Introduction
O. Gorter 
of how we use a computer today; creating a system where there is no longer a difference on what you see on
your screen and what is stored on the hard disk.
. Relevance
In the “References” we see more works that try to extend the file system with searching. And it is a very
relevant idea, because lately it is sometimes easier to find things on the enormous internet, using google, then
on your own hard drive. You can always use a search, but it is slow and not very ubiquitous.
This is known by the two mayor os software vendors, Microsoft and Apple: both announced a more integrated
search using some sort of database. But we will have to wait a while until the new products are available.
But already we can see what a non-hierarchical approach to files can do when we look at specialized applications
like iPhoto or Adobe Photoshop Album for digital photo management, or iTunes for digital music.
Database File System
O. Gorter 
Hierachy Based File Systems – Theory
—2—

This is chapter is an overview of how to days (hierarchical) file systems work from a high level point of view.
Where appropriate some forward references are given to the database file system. Four properties of hierarchy
based filesystems are discussed, with an emphasis on their weak points. But we start with a description of what
a hierarchy based filesystem actually is.
Hierarchy based filesystems are created by directories and files. A directory is an object wich has a name and
it can contain directories and files. Files are objects that also have a name and contain data. This data can be
anything and is only relevant for the application that uses this data; the file system does not impose what the
data must look like, in fact, this data is not shown in the file system. We use a file system in order to keep track
of this data, by keeping track of our files. We keep track of our files by knowing their name and the directory in
wich they reside.
This type of filesystem creates a two dimensional space laid out as a tree like structure. This structure is
created from directory names and depth of directories. (Also see
Figure 2.1.) By choosing useful names for
directories, we effectively create a categorisation over sub-hierarchies (sub-trees) and the files they contain. For
example, a digital picture from a certain user on a MS Windows system would typically be found somewhere
below: /Documents and Settings/username/My Pictures/. We can trace back why the picture would be
stored there: The picture is a document, therefor it should be in Documents and Settings; The picture is from
’username’ therefor it should be in username; and it should be in My Pictures because it is a picture.
Database File System Hierachy Based File Systems – Theory
O. Gorter 

C:
Documents And SettingsProgram FilesWinnt
User1 User2


My Documents My Pictures
Figure 2.1 A typical MS
Windows XP hierarchy.
Modern hierarchy based file systems like ntfs, hfs

+
and also ext, reiserfs and more, have lots of optimal-
isations regarding how files are stored and retrieved. Using techniques like journalling, binary balanced trees,
hot-file tables and more. These techniques enable these systems to pe rform optimally, but on the outside they
all use the same hierarchical approach. This chapter will only discuss the basic properties that come from a
hierarchical approach, not the properties that come from their implementations. Especially when realizing that
the techniques used in these implementations will not be invalidated when moving to another type of file systems,
for instance, most database implementations are also highly optimized, perhaps even more so then file systems.
Database File System Hierachy Based File Systems – Theory
O. Gorter 
. Properties of Hierarchy Based File Systems
.. URLs
Using directories and files, hierarchy based file systems create a unique name for every file; referred to as the path
or as we will do here, the url. This is one of the strongest points of a hierarchy based file system. An example
of a url is /Documents and Settings/username/My Documents/University/Final Project/report.doc A
url is a clear means if identifying one file, and one file only. Hierarchy based filesystems are based on urls, or
create urls, depending on your point of view. This property comes from the fact that inside a directory there
can be only one object (file or directory) with a certain name. Otherwise a url could point to two or more files
at same time, without a clear way to know which file it actually refers to. urls are a feature lost in the database
file system, at least to some extend. There is more about this in the discussion of the database file system, see
“Database File System – Theory”.
It is important to note that urls are very useful and part of the reason why hierarchy based file systems are
designed the way they are. It gives both computers and humans a way to refer to files uniquely. The next
three properties to be discussed are very much connected to the url creating property, but instead of being an
advantage only, they are the properties that are the main motivation for a new file system.
.. Hiding
Directories hide what is inside of them, directories were designed to work this way, it is what ke eps the file
system tidy and arranged and therefor useable; but there is a downside: Because directories hide what is inside
of them, there could be an endless set of sub-directories inside a directory. There is no way of knowing what is
inside a directory until you traverse into it. The consequences are that, if categorisation using directory names

fails, or is unclear, then a file can be hidden. There are tools to locate such ‘lost’ files, but wether they are able
to help depends on the situation.
Database File System Hierachy Based File Systems – Theory
O. Gorter 
.. Locations
Directories create locations, this enables users to create meaningful locations to store certain files. But many
directories means many locations, which might mean too many locations; which makes it hard to find the right
location to store documents. Also, documents can be stored at only one location, meaning that you need to find
the right location if you want to find a certain document.
To make matters worse, most systems don’t put emphasis on locations anymore, they emphasize the next
property, hierarchy, instead. The problem here is that lo c ations are easier (less abstract) to understand then
hierarchy, especially for less computer literate people. Stressing locations can be done by not allowing users to
create two windows on the same directory, opening sub-directories in new windows and presenting one directory
always in the same window at the same location with the same layout. This way a user recognizes his documents
directory not only by its url, but also by its window layout and position.
The reason for the shift to hierarchy and away from locations is the ever growing size of the file system and the
amount of files we store. With too many locations it is hard to identify locations. Notorious good systems that
placed lots of emphasis on locations were Mac OS 9 (and below) and Risc OS. Also earlier versions of Microsoft
Windows placed more emphasis on locations then they do today.
.. Hierarchy
Directories create a hierarchy and we do our best to create hierarchies that split up sub-hierarchies using mean-
ingful properties, in doing so we are categorizing our files. But not everything kan be fitted inside a hierarchy
and the larger part of the hierarchy is created ‘backwards’’: because hierarchies are a must we impose hier-
archy on our files. For example: a msword document is stored in (on a MS Windows system) /Documents
and Settings/username/My Documents/name.doc. Even though this is the most logical place to store such
a document in a hierarchy based system, there is too much hierarchy imposed on this location: The docu-
ment is a subset of Documents and Settings but not so much a subset of username , let alone Documents
and Settings/username. Arguably the hierarchy should have been laid out like /username/Documents and
Settings/My Documents/name.doc, because Documents and Settings is more a subset of username then the
Database File System Hierachy Based File Systems – Theory

O. Gorter 
other way around. And where do we store programs only for one user? Clearly programs do not fall in the
category Documents and Settings. So we cannot store them at Documents and Settings/username. Instead
we need to create a new username categorisation somewhere else where we do store programs, like Program
Files/username.
The problem of imposing hierarchy becomes even clearer when thinking ab out other file properties like security,
ownership, encryption and sharing. If we want to share a file with another user, perhaps even over a network,
most of the time we must move (or copy) the file to a public location (directory) and set the rights to the
file correctly. Because the concepts of ownership and sharing work through the hierarchy, we need to create
a different hierarchy to prevent all our files from becoming public all at once. Two hierarchies to store our
files means keeping track of them even becomes harder. This principle of splitting the hierarchy based on some
properties of what is inside the sub-hierarchies is not always effective; sometimes we have documents that easily
fit inside both sub-hierarchies. Which one is the best hierarchy to place that file? Probably none. Prope rties
over files just are not one dimensional and how we would like to categorize these dimensions depends on our
point of view. When sharing files, we want those files to be placed somewhere in the hierarchy where the are
actually shared. But when trying to retrieve certain files, we would like them to be in the most logical place in
the hierarchy. Unfortunately these two views on where the files should be stored are non-reconcilable.
There is a good reason why categorizing our files with directories has it shortcomings. The properties over
which we are trying to categorize are all different kinds of properties. In the example /Documents and Set-
tings/username/My Documents/University/Final Project/report.doc, the first categorisation is made over
the type of the file (Documents and Settings), the second categorisation is made over the owner of the file
(username), then we categorize again over the type of file (My Documents), and finally we categorize twice over
the role of our file. And only the last part of this categorisation is a truly hierarchical relationship.
A last issue with hierarchy is its abstract nature, also see the previous property of locations. If we want to keep
our file system organized we must create hierarchies, preferably meaning-full ones, in order to keep track of our
documents. This is a difficult task for less computer literate people. It is hard to understand that a directory
can contain a directory. The reason this is difficult, is mostly because there is no real life example that has
somewhat the same properties. A house contains a closet that contains a box that contains a photo album that
Database File System Hierachy Based File Systems – Theory
O. Gorter 

contains a certain photo. Not a hard-drive contains a box that contains a box that contains a box that contains
a certain photo. And even when there are boxes inside other boxes, the first box would be a big box.
Today most systems take a middle road between locations an hierarchy. They treat certain directories as locations
and from there create hierarchies if necessary. Examples are the My Documents and My Pictures directories on
an MS Windows system. These two stand out with their own icon and when opening such a directory they have
their own themes.
Database File System
O. Gorter 
Database File System – Theory
—3—
In the previous chapter we discussed current (hierarchical) file systems. Four properties were analysed that
are inherent to hierarchy based file systems. The final conclusion was that those file systems impose to much
hierarchy without a choice; the hierarchy forces categorization over different properties that don’t have hierar-
chical relationships with each other. This chapter presents the idea of the database file system in a high level,
non-technical, overview; explaining the overall design and workings. The main differences with hierachical file
systems will be pointed out.
The dbfs does not impose hierarchy by storing all files in one big data store, or database, hence the name
Database File System. It stores files without any restrictions on the files; multiple files can be stored with the
exact same meta-data. It is almost like storing all files in one directory, but without the need for unique names.
To retrieve files, the big store of files can be reduced by telling the system what files to look for. Like all files
that were modified today, or all files called report. The queries on the system can include any sort of meta-data
that is associated with files. This introduces a new powerful feature to a file system: You can retrieve files
independed of the perspective you took when storing them.
A little example to explain this some more, suppose you are looking for a file: If you remember you edited your
file last week, you can look for all files edited last week; If you remember giving it a certain property, you can
look for all files that have that property; If you remember you made someone else the owner of the file, you can
look for all files owned by that owner; If you remember at least some part of the file-name, you look for all files
containing that part in their file-name; Or you can use any combination of the above to look for your file.
Database File System Database File System – Theory
O. Gorter 

Because the dbfs does not use directories anymore, there are no more custom properties you can categorize files
on. To reintroduce this the dbfs uses keywords, a file can have zero or more keywords, and the keywords can be
used in a search. Keywords can be seen as the new directories. Keywords are a superset of directories in view
of their capabilities; keywords can do what directories can and more. More on this later in this chapter.
From here on, the data store of files will be called a view, just like any subset from this store of files is called
a view. And a search or query will be called a filter. A view is created by a filter, and every view has a filter;
basically, a filter defines the files you are looking at, hence a view. The reason not to use search or query, but use
filter instead, is because search or query sound too much ‘single-shot’, though the terms are almost analogous.
. Relevance
In comparison to a hierarchy based file system, the dbfs is much more powerful in how to store and retrieve
files. But it does sacrifice the notion of urls. The dbfs can produce urls by using unique file identifiers, much
like inodes, but not by using symbolic identifiers, like the path in a hierarchy based file system.
The dbfs can get away with this limitation, because it services a different goal then todays file systems. The
dbfs is targeted at the use r by only storing do cuments (ie. files the user is interested in). You could see it as a
document retrieval system. Consequently it does not store system files like shared libraries, configuration files
and others. These files should be stored using apis, for instance using a hierarchy based file system.
For the dbfs to perform optimally, it is not so much that files should be stored; instead documents should be
stored. Lots of programs today use multiple files as one document. A few examples: An ide uses multiple
files as source and header files (and more), but all these files are related and form one do c ument. Movies are
often stored as multiple files, a part one and part two, and two subtitle files, one for each part, again, all files
are related and form one document. Applications (especially under MS Window s) typically come with a whole
bunch of files, but none of these files make sense unless in the context of the application, again, an application
is one unit and should be treaded as such.
It is not that all files should be stored as one large file, but more that closely related files should be treated as
one unit. And the dbfs should provide the means to do so.
Database File System Database File System – Theory
O. Gorter 
. Categorisation
The dbfs categorizes files on any property they have, which creates a multi-dimensional categorization, as
opposed by hierarchy based file systems that have a one-dimensional categorization applied multiple times.

In the dbfs only some categorizations are hierarchical, where there are hierarchical relationships (types and
keywords). In a hierarchy based file system every categorization is hierarchical, even if there is no hierarchical
relationship. It is important to realize that pushing categorizations in hierarchy decreases the categorization its
usefulness. The way the dbfs categorizes is called a faceted system.
With an simple example we can explain a faceted system and its powers over a hierarchical system. Lets say
we are looking at carrots and oranges. They share the properties that they are both edible and orange, but the
first is a vegetable and the second is a fruit. Also both could be from Europe, but the first is probably from the
Netherlands and the second from Spain. All these properties have no relationship between them: being orange
has nothing to do with being a vegetable. Only Spain and Europe have a relationship, which is a hierarchical
relationship because Spain is part of Europe.
In a faceted system we can create a categorization on both the carrot and the orange in a very natural way.
Such that we can ask the system for a orange vegetable and we see a carrot. Or ask for a vegetable from the
Netherlands and see a carrot. But in a hierarchy based categorization, there is a fixed order of the properties
and only when we traverse this order can we know about the properties of an object. If the first categorization
is on fruit or vegetable, then it is impossible to retrieve all edible things from Europe. Or if we are making an
orange salad, it is impossible to retrieve all orange edible things.
The main difference between a hierarchy based system and a faceted system (like the dbfs) is that hierarchy
based systems are made to store things in some (reasonable) logical location, as where a faceted system is made
to categorize and find things. Hierachy based systems are what whe use in the physical world to categorize things.
In a supermarket, oranges would be stored in the fruit department, and carrots in the vegetable department.
But the fruit and vegetable departments are in the biological food department, a hierarchical ordering on the
role of the product.
The reason we use such a system is because fysical objects can only reside in one place at the time, were as this
limitation does not go for virtual objects, like files. So there is no reason to limit a file system to a hierachical
Database File System Database File System – Theory
O. Gorter 
system, when a faceted system is more powerfull, and could be considered a super-set of hierarchical systems.
This is why the beginning of this chapter stated that keywords are like a super-set of directories: A location in
a hierachical system is defined by its elements in the hierarchy, using these same elements to query a faceted
systems yields the same results.

In the example of /Documents and Settings/username/My Documents/University/Final Project/ this lo-
cation in a hierachy based file system is the same as querying the dbfs for all Documents from username where
keywords are University and Final Project. Only there is no hiding, when the /Final Project/ directory
contains more directories, these show up as directories in the hierarchy based file system, but their contents
shows up in the dbfs.
Database File System
O. Gorter 
Database File System – Overview
—4—
In the previous chapter we discussed the theory behind the dbfs. In this chapter a high-level overview is given
of the current implementation us ed in this research. It will start at the bottom and end at the gui that has
been implemented in kde.
The dbfs has been implemented as a daemon service for unix like systems, which integrates a sql library and
accepts connections from clients. The clients are the open-file and save-file dialogs in the open-source Desktop
Environment kde, together with a standalone filemanager, called kdbfs, which replaces Konqueror. Running
this setup of kde gives the impression to a user that there is no hierarchy based file system, only the new
database file system.
The daemon service is called dbfsd and runs in the background. It does not actually store files, it only stores
references to files on the hierarchy based file system. The dbfsd tries to work together with the underlying
hierarchy, such that a high level of backwards compatibility is achieved. In the current implementation it only
supports a few pieces of meta-data: file-name, file-type, file-size, modification-date and keywords. And the server
is only meant to service one user, but every user can run its own instance.
The dbfsd can be configured using the .dbfs/dbfs.conf file in the users home directory. The main purpose of
this file is to tell the server what directories to scan and where certain new files go, according to their file-type. It
can also be set to ignore certain directories or files. Which mime-type to use for which file extension is configured
in .dbfs/mime.conf. A log goes to .dbfs/dbfsd.log and the actual database is written in .dbfs/db.db. The
next chapter will go much deeper into its implementation.
Database File System Database File System – Overview
O. Gorter 
KDE

dbfsd
Hierarchical File System
File Access
Figure 4.1 Overview
of the new kde.
What the user sees when using the kde implementation from this research, is a normal functioning s ystem,
until the user accesses a open-file or save-file dialog. These fundamentally differ because they use the dbfs. But
because the dbfsd does not actually store files, only their references, while the user might see a different file
system, a kde application sees and uses normal files as if there was no dbfs. This is important because the
kde applications do not need to change in order to work with the dbfs. (Also see Figure 4.1.)
. User Interaction
The main kdbfs application is shown in Figur e 4. 2, with this application the user can lookup and manage files
in the dbfs. This application replaces Konqueror which is the file manager of kde in a hierarchy based system.
(It should be noted that Konqueror is also the internet browser and more, because it is very modular in setup,
these functionalities have not been disabled.) The kdbfs application reflects how the dbfs works internally,
with filters and views, as kan be seen in the figure.
Database File System Database File System – Overview
O. Gorter 
Figure 4.2 The kdbfs application. The number 1 is the view, numbers 2
through 5 are filters.
Whenever the user manipulates a filter, the view follows the filter immediately, providing direct feedback. And
because the view updates in the background, the user can continue to manipulate the filters, even when thousands
of files show up. The user can manipulate how the view is rendered using the few buttons just above the view,
which toggle the zoom level; overall layout; and sorting on name, date or size. Right next to these buttons is a
search field (number 5 in Figure 4.2), which searches the file-name by manipulating a file-name filter. Files in
the view can also be renamed.
Database File System Database File System – Overview
O. Gorter 
.. Filters
Just ab ove we already mentioned the name-filter, which is implemented as a search field. All other filters the

kdbfs offers are implemented as widgets, located next to the view. These filter-widgets can be hidden or shown
by the buttons at the very top of the application. The current implementation has only three of these filter-
widgets: a general main-typ e widget (numbers 2 and 3 in Figure 4.2); a keyword widget (number 4); and a
date widget (not shown in figure).
The general main-type widget has two functions. First it can select on one or more of the main file-types there
are in the system, like documents or images and more (number 2). But it also supports saving the current filter
(number 3). Which means that the user can save a view he created and quickly retrieve that view, without
having to click around to recreate the accompanying filter. Moreover, after using a stored view, the rest of the
filters can be used to create sub-views on the stored view.
The date widget can select a date range which will select all files that have a modification dates inside that
range. Unfortunately the c urrent implementation is not an optimal one, it is just two calendars on which the
user can click. A more optimal widget would display one calendar, which should be zoom-able, and ranges can
be created by clicking and dragging on the calendar. Also it is not possible to select on creation-date or last
access-date.
The keyword widget is probably the most important one, because it supports user defined categorisations. The
user can create new keywords, and rename or delete existing ones. The use r can also drag keywords around to
create hierarchical relationships between keywords. If a keyword is selected, the view will show all files which
have that keyword associated with them. Multiple keywords can be selected, and the view will show all files
which have at least one of the selected keywords associated with them (an or operation). When a keyword is
selected that has multiple keywords beneath it in a hierarchical relation, the created filter will be as if all the
keywords beneath and the selected keyword had been selected.
To add keywords to files, the user has a few options. One or more keywords can be dragged onto one file or
a selection of files, these files will then add these keywords to their meta-data. The user can also drag one or
more files on a keyword. Or the user can drag one or more files on an empty space in the keyword widget and a
new keyword will be created, which the user must give a name. Another function of the keywords widget is the
Database File System Database File System – Overview
O. Gorter 
inverted mode. In this mode the whole filter is appended with a not. This is useful when categorizing lots of
files, because the files already categorized will disappear from the view.
The behaviours of the filter-widgets are very natural, but chosen quite arbitrary during the development of

the kdbfs application. The dbfs supports much more powerful filters then can be created using the widgets
described above, but in order to keep the system simple, this implementation has been chosen. To really get a
feel for how the filters work together, the reader should be enabled to click around in the application himself.
More on the usability of the dbfs and the gui can be found in
Chapter 6.
.. Dialogs
The new open-file dialog is quite similar to the kdbfs application, except most buttons to manipulate the
keywords and the view have been removed, keeping the focus of the dialog on opening files, and not manipulation
file meta-data. For kde application that tell the dialog which file types it can open, the dialog displays only
those files by setting an appropriate filter. This can be disabled using a little checkbox located on the bottom
of the dialog. Also see Figure 4.3.
The new save-file dialog is completely different from the original. There is no need for an extensive dialog,
because the dbfs does not use locations. The user can enter a name, optionally add a keyword or keywords to
the new file, and press Save. For those kde application that tell the dialog what file-type to save to, the user
can leave out the extension. Also see
Figure 4.4.
It is unfortunate that kde is not very focused on meta-data, and not all applications tell the dialogs what types
they can open, or what type they will use to save. This can be confusing because the dbfs save-file dialog only
asks for a file-name, not a file type (in the form of a file-extension). Happily the KOffice suite fully supports
file-types when saving or opening. But for instance when Konqueror saves a file from the internet, it does not
relay its type to the dialog, the user should manually append the name with an extension. This shortcoming is
not permanent, and will be resolved if kde gets better file-type support or works together with the dbfs more.
Database File System Database File System – Overview
O. Gorter 
Figure 4.3 An open-file dialog.