PennFS: A File System on Relational Database
Dept. of CIS - Senior Design 2012-2013
Jin You
youjin@seas.upenn.edu
Univ. of Pennsylvania
Philadelphia, PA
Di Mu
dimu@seas.upenn.edu
Univ. of Pennsylvania
Philadelphia, PA
Hongda Ma
ma1@seas.upenn.edu
Univ. of Pennsylvania
Philadelphia, PA
Boon Thau Loo
boonloo@seas.upenn.edu
Univ. of Pennsylvania
Philadelphia, PA
ABSTRACT
PennFS, a Windows 8 Store Application, aims to visualize and simplify the user experience of file management by im-plementing an alternative file system that is better indexed and organized through relational database. The traditional hierarchical file system has several limitations; especially, when files share multiple relational properties, one file may relate to multiple folders, and the primary search method using keywords is not universally efficient. To resolve this problem, a tagging system is implemented using database de-sign principles to index the filesystem. In PennFS, a new application layer based on relational database and Language-integrated Query (LINQ) is introduced to coordinate with a user interface built with C#/Extensible Application Markup Language (XAML) [9], local file system accessed using Win-dows Software Development Kit (SDK) for WinWin-dows 8 [10], and an email system accessed using Limilab application pro-gramming interface (API) [6].
1.
INTRODUCTION
In almost every mainstream operating system, a hierar-chical file system with a tree structure and extra utilities allowing search by keyword is used to store files and doc-uments. This structure has remained unchanged for many years while the daily usage of computers soars and the com-plexity of file relationships increases, so it is very helpful to develop new ways to facilitate file searches.
Several problems are innate in traditional hierarchical file system which is based on the tree data structure. First, since the files are always treated as leaves of a tree, as the number of files increases, users have to build complicated tree structure to classify the data manually, thus extending the time of file management. Secondly, the more relation-ships the files have, the deeper and more complex the tree becomes. In many cases, since the files are hidden deep in the tree structure, search for files become very inefficient. Thirdly, files sharing common features may scatter in many places in the tree structure, so users who want multiple files at the same time have to search in many locations to collect all the files. Fourthly, users have to save duplicate files un-der different folun-ders if they want to organize files according to multiple relationships. Finally, the current file system does not support management of email and files in online
collaboration system.
The current file system made many attempts to solve the problems. For example, to reduce the time of going deep to the folder of folders, current file system allows the user to create shortcut to files and favorite folders on desktop. Also, current file system accelerates file searching by allow-ing search by keyword. However, these solutions are still limited by the disadvantage of tree structure in current file system.
A customized view based on a relational database is an ideal way to resolve this problem. Using a relational database to manage the file information, the limitations of the tree structure in hierarchical file system can be mitigated. After users attach multiple tags onto a file, tags can be digested by the relational database as indexes to facilitate the search process. One advantage brought by this tagging system is that only one copy of file is required in the system to present files in multiple views. In addition, database layer is able to translate and forward a user query to search for data in both local file system and email. At last, since the relational database stores only file metadata, it allows easier integra-tion with other platforms.
To implement the above idea, PennFS integrates the user interface using Visual Studio 2012 with Blend [8], a local file access system using Windows SDK for Windows 8, a Gmail file system access system built with Limilab API, with a database management system using LINQ. PennFS builds a relational layer on top of the hierarchical file system and con-nects the database includes Windows 8 file system metadata so that files under the same tag, including user-defined tag and system-recorded tag, could be searched and managed by LINQ queries. Secondly, metadata from online email service and online file storage platforms is recorded in the database. Examples include email metadata from Gmail. In addition to the feature of searching for files, PennFS supports search-ing of tags from the database. With this feature, when searching with keywords, users could avoid placing multi-ple queries in various products such as mailboxes and cloud storage.
2.
RELATED WORK
This section discusses related work includes the origin of the idea of relational file system, WinFS, an attempt of implementation database file system on Windows platform,
tagging system in Gmail, and database connection.
2.1
Idea of Relational File System
Hierarchical file system is the most traditional and commonly-used file system. With a tree-like data structure, it is con-venient for users to navigate at front-end and easy for de-velopers to implement at back-end. However, hierarchical database has its limit; it is too specific and restrictive on defining a file since one file can only belong to one folder. Many theoretical and practical works have been done to im-prove the file storage and management. Here we want to discuss the idea of building a file system based on relational database principles. In 2005 File and Storage Technologies Conference, a suggestion that filesystem should borrow ideas from database was presented by Dr. Jim Gary [3]. Later in his technical report published in 2006, he argues that, unlike what previous folklore suggests, file system performance may be improved by using database techniques to handle small files [12].
2.2
Relational Filesystem on Windows
On Windows platform, the project that most closely re-sembles our approach is WinFS, an advanced storage sub-system project for Windows platform. WinFS, developed but later cancelled by Microsoft in 2003, was intended to be a revolutionary file storage system which empowers users to search and manage files based on content [5]. It introduces the idea that everything is an item, and each item has meta-data properties that are described by a schema. Unlike the small projects for Unix mentioned above, WinFS intends to change the structure of file storage to allow a single item to exist in more than one WinFS folder. PennFS adopts some ideas of WinFS. First, the WinFS UI, unlike the traditional hierarchical folder view, is very friendly to users with com-plex projects by embodying many data visualization ideas not traditionally in hierarchical file system, such as timeline and graph. Also, the searching in WinFS is a process of organizing the relationships across the data and connecting them together.
2.3
Tagging System: Gmail
The tagging system in Gmail, one of the most popular email services provided by Google, a simple and efficient way to organize messages. With two important features, Gmail’s tagging system inspires us to build a similar system in our application. First, it does not limit the number and names of labels; users are able to classify a great number of emails into categories like work, family, to do, read later and any category users want. Secondly, while labels do all the work that folders do, users are able to add more than one label to one message. Thus, we decided to build a tagging system in our application to help the user to classify and find the files more conveniently. Especially in the searching process, the tags can be transformed to search query directly; as a result, users with little background of database are able to utilize the advantages of database.
2.4
Database Connection: LINQ to SQL
Our application requires the communication between our development programming language C# and the SQLite database, and LINQ to SQL [2], a component of .NET Frame-work version 3.5 provides a run-time infrastructure for man-aging relational data as objects, solves the problem. LINQ
to SQL maps the data model of a relational database to an object model expressed in the programming language of the developer, which is C# in our application. It translates developing programming language into SQL the language-integrated queries in the object model and sends them to the database for execution at run-time. Also, LINQ to SQL translates the return result from database back to objects so that developer can work with developing programming language.
3.
SYSTEM MODEL
Figure 1: System Model Diagram
PennFS builds an alternative file system on top of the ex-isting New Technology File System (NTFS) system in Win-dows operating system. As shown in Figure 1, it consists of five major components including user interface, API infras-tructure, file systems, email, and relational database.
i) User Interface: The user interface, a Windows 8 Store Application, presents the file system view in a clean and user-friendly fashion. It allows user to create and assign tags to file from local file system and emails. User should be able to configure the backend, set email accounts. This module also takes different user requests such as search and files access, and sends it to the API infrastructure. After hearing back from the backend, the user interface will visualize the search results and file previews.
ii) API infrastructure: the API infrastructure layer glues all the other four components together. It takes requests from the user interface and propagates the query to the rest of the system after proper translation of the request. At the same time, it collects the results and return to the user interface. Since this component is doing all the heavy lift-ing, the load for the user interface could be largely reduced. In other word, minimum modification needs to be made in the user interface when we are extending our application to be compatible with new platforms such as new online email folder and collaboration folder. The extensibility of the ap-plication is largely increased.
iii) Local File system Access: this component deals with all the requests for the local file system. It interacts directly with the operating system, fetching metadata, opening files and making edits. It is commanded by the API infrastruc-ture and performs the request as long as the request is within the authorization of the system.
are also managed in a similar fashion nowadays. As they are becoming an indispensable part of our life, we want to inte-grate emails into our system to enhance the user experience. Since people organize emails into different folders for future lookups, this component is very similar to local file system module in terms of functionalities.
v) Relational Database: The database component stores and manages the entire file metadata and customized tag-ging information. It executes query requests from the API infrastructure and returns the result back to the central com-ponent. As the metadata information is very small, a large amount of redundant entries might be stored to optimize the search performance.
Figure 2: Search Scenario
Figure 2 shows a scenario of searching. Once user makes a search query (such as searching for all the files under tag “cis400”), the application would respond in the following manner. 1) 1 : The UI forwards the requesting informa-tion of tag and file source to the API infrastructure.
2) 2 or 4 or 7 : The backend generates separate query for different data stores and propagates the result at the same time. For local file system, it sends the query to local SQLite database with database connector. Another query of different format but same content is also sent to the email system through email connector.
3) 3 or 5 or 6 : API infrastructure collects the result from the database and the email system. The result is inte-grated to a uniform format.
4) 8 : The integrated result is propagated back to the front end, the UI organizes the result into a user friendly view.
In general, the system provides a simple interface to the user while hiding all the complexity in the backend. In the case of tagging and searching, a single query is translated to multiple queries in the API Infrastructure first. Every trans-lated query is then forwarded to its respective connector to perform the required jobs (in the database, on the email server and so on). All the feedbacks received by the connec-tors after the jobs are completed return to the user interface. The user interface is responsible of parsing and formatting the feedback before presenting it to the user. Similarly, when the user wants to open a file from the user interface, the API
Infrastructure calls the local file system for the user.
4.
SYSTEM IMPLEMENTATION
This sections explains the implementation of front-end user interface, and back-end including file access and email access in PennFS.
4.1
Front-end Design
The user interface (UI) of PennFS is a Windows 8 Applica-tion adopting the Windows ApplicaApplica-tion Store development framework [10]. Since the focus of PennFS is to provide the user with a fluid and intuitive experience in file management, “Metro” the Windows 8 UI design style which embodies sim-plicity and the distinctive “touch-first” interaction, became our first choice.
The UI consists of two parts; the layout and styling are implemented using XAML, and the controller and data ac-cess are implemented using C#. Blend for Visual Studio 2012 [8], a styling tool that automatic synchronizes be-tween Blend and Visual Studio is used to edit the XAML files. The XAML, a declarative markup language, is cho-sen because it simplified the creation of UI, especially under .Net Framework by allowing developers to create visible UI elements and to separate the UI definition from run-time logic. C# is chosen as the primary language for user in-teraction implementation because it is commonly used to develop applications that run on the .NET Framework [9]. Its compatibility with .NET framework and abundance in library documentations made the development of user in-terface very convenient. Moreover, with a simplified syntax compared to C++ syntax, C# provides many useful fea-tures such as nullable value types, enumerations, and direct memory access.
4.2
Local Filesystem Access
In this section, the discussion concentrates on the code-base which supports Windows 8 local filesystem access. First, the overall assessment and justification of the local filesys-tem design decisions are described, including development toolkit and programming language.Then, five topics are cov-ered in this section regarding the implementation.
The entire suite of local file system access interfaces was developed using Windows Software Development Kit (SDK) for Windows 8. It is adopted as the development infrastruc-ture of PennFS because it provides a comprehensive set of libraries and tools to build the new Windows Store appli-cations introduced with Windows 8 [10]. Since Windows 8 SDK is a first-party development toolkit from Microsoft, it provides a number of key features required in PennFS. To name a few, it encapsulates the managed .NET Framework programming model which is essential in Windows Store application development. It functions seamlessly with Vi-sual Studio 2012, the major IDE. Also, it has a sufficient and complete set of documentations and samples for each API. Lastly, it includes the Windows App Certification Kit (ACK) for application testing and verification, a feature that has been shown extremely beneficial to PennFS.
Given its native compatibility with our development tools and its comprehensive development facilities, Windows 8 SDK has exhibited both consistent performance and high efficiency and has been proved to ease the complexity dur-ing debuggdur-ing. As discussed intensively in the User Interface section, the primary programming language is C# for
front-end. To reduce the implementation complexity introduced by inter-process communication, the local file system access utilizes the C# interface package from Windows 8 SDK.
Listed below are six completed features developed using Windows 8 SDK for PennFS and their respective function-alities in the system model in Section 3.
i) Retrieval of file and folder properties. This suite of interfaces enable PennFS user to view the selected file and properties in Windows 8 local file system. The file property list provided to the user includes filename, file type, file size, date modified, date accessed and file owner while the folder property list includes folder name and date created.
ii) Creating, renaming and removal of a file or folder. This set of interfaces is crucial in supporting the system model since a user of PennFS should be able to modify the local file system.
iii) Aggregate selection of one file or folder or multiple files. This interface has significance in allowing the user to perform file operations. Before a user could either access or modify the file or folder, a measure should be provided to select the file or folder for the action. Therefore, PennFS provides aggregate file and folder selection through Windows 8 SDK. However, the limitation is that only one folder could be selected at one time due to one application constraint on Windows Store Application.
iv) Retrieval of file or folder thumbnails. First, the file and folder thumbnails are different from each other. The file’s thumbnail might be an icon for a PDF file, a preview for a picture-type file or a note symbol for a music-type file while the folder’ s thumbnail is an icon of a folder. The user interface component of PennFS requires displaying file and folder thumbnails as well as file and folder properties.
v) Tracking the most recently accessed files or folders by the user. This feature is particularly useful in providing the tagging functionalities. This task needs the backend capability to track the most recently used (MRU) files, which is provided by this interface. A MRU token is stored in PennFS to retain access to the same MRU list. This feature can be used together with tags, described in section 4.4, in determining the most recently used files under a particular tag.
vi) Keyword search on local file system. This feature is crucial for the realization of keyword-based tagging because it provides intuitive native search functionalities.
4.3
Gmail Filesystem Access
In this section, the design decisions for the Email Sys-tem and the choice of Email client API are discussed. First, Gmail was chosen as the first email server to integrate. Sec-ond, the language on which the email module was imple-mented on is narrowed down to C#. Then, a third party API, Mail.dll by Limilab, is chosen to be a temporary so-lution that works well with rest of the components. Fur-thermore, the idea of writing a new email clients for better compatibility of the system will be discussed in the Future Works section.
The email component of our system was mainly modeled based on Gmail email system. In addition, Gmail already has a built-in labeling system on its end. Hence the labeling function for emails in our system could be managed directly by Google, which reduces the burden of our local database by storing less data for each index.
Gmail supports the standard Internet Message Access
Pro-tocol (IMAP) and Simple Mail Transfer ProPro-tocol (SMTP) protocols for operations on email. It only requires Transport Layer Security (SSL) and could be access the same way as accessing any other standard email systems.
On the Java side, Oracle provides a JavaMail API for all Java developers to build mail application. The API is stable and less prone to bugs. More importantly, it was used by a number of developers in the community. Plenty of well written tutorials could be found online. The way JavaMail works is it connects the IMAP server with an instance of the IMAPStore class. It is an instance of the Store abstract class in the API. The store could connect to the IMAP server with user credentials. All the messages in any folder could be downloaded and from the server once the stored is con-nected. The attachments could also be downloaded to the local file system.
However the difficulty with JavaMail is to integrate the email module with .Net platform where the front end was built. While it was extremely convenient to manipulate the Gmail folder with JavaMail, it was relatively complicated to invoke the Java program from the .Net system. For exam-ple, the API infrastructure would call the email connector to fetch the file if the front end is trying to access the file from the Gmail. The call to the connector (in Java) from a dif-ferent platform (.Net) requires additional mechanism. One solution is to maintain a common variable, such as entry in the database, some temporary file on the file system, as sig-nal and run a Java thread at background to monitor such change. This is quite expensive in terms of the clock cycle wasted when running the application as the Java program is busy waiting in the entire lifespan of the application. An alternative solution is to build a bridge between Java and C#. There are several such implementations available, in-cluding paid and open source versions. The paid version is too costly to use, and the reliability of the open source bridge was questionable, and they were also expensive to implement because it created Java Virtual Machine while running the C# program.
On the C# side, it would be straightforward to embed the connector into the API infrastructure module in our system as the front end was also written on the .Net framework. However, there was no official email library developed on the .Net framework yet. Therefore, a third party C# library was used to establish the IMAP connection for the application. A few free libraries were examined, but none of them was well maintained. For instance, MailSystem.Net [11] was one of the libraries explored. It was a complete library with SMTP, POP3 and IMAP support. The download package also contained many samples for different usages. However, the project was not updated for years and there was no longer any good support for the build issue occurred while runnning on the current system.
Open source libraries were also not chosen due to the in-compatibility. An open source library, AE.Net.Mail, was previously a major focus prior to the integration of all mod-ules in our system. However, even it was implemented in C#, the API could not be directly called by the Windows Store App. The reason was that the library was imple-mented as a old class library in C#. .Net for Windows store apps, the platform where the user interface was im-plemented, is incompatible with the traditional C# class library. Several standard C# libraries used in AE.Net.Mail no longer exist in .Net for Windows app.
As a result, Mail.dll by Limilab was integrated into the system as a major part of the mail connector. Mail.dll is a paid API developed by Limilab. It offers a trial version with little limitation in the functionality such as not showing the title of the email. Despite the limitation, the API is compatible with Windows Runtim and .Net for Windows store apps. Moreover, even though it was close source, the API is well documented and easy to understand. So far the best solution to circumvent the lack of .Net email library was to use Mail.dll in C#. To access an email or attachment in Gmail, the email connector could call the functions in the Mail.dll API directly without any cross-language bridge. As most part of the application is written on .Net framework, using Mail.dll is better than the Java solution because it does not add any overhead to the API structure. To have a more compatible email component, a licence for Mail.dll need to be purchase to reach its full functionalities.
4.4
Database Management System
In this section, the reason that PennFS uses relational database, SQLite, for backend storage system is explained. Then, the entity-relation diagram of the database tables is included and design decisions of the diagram is provided. Lastly, a list of existing interfaces provided to the front-end user experience module is introduced.
From the previous system model section, the tagging in-terface and system have been introduced and they are vital in PennFS. It is the role of tagging system to produce an ag-gregate view of files, folders and emails to the user. There-fore, tagging support is of major concern in the backend stor-age system design. Among the options of relational database and key-value database, the former has a distinct advantage in achieving the tagging system since relational database na-tively supports indexing on its database table entries. It is readily noticed that indexing is an interchangeable concept with tagging because they both are mechanisms in grouping data entries, thereby supporting the fast retrieval of data entries under same group [7]. For instance, the relational database sets the “tagˆa ˘A˙I property as its primary index in storing the data entries. If a query requests for the entire group of data under a particular “tag” property, the rela-tional database uses the indexing mechanism to return the data entries directly. This correspondence encourages the usage of relational database.
One limitation of the relational database system is that its scalability in indexing and returning query results is ques-tionable if the data entries are of large volume. However, because the scope of PennFS concentrates on the metadata of files and folders from local file system, online email ac-count and online file depots, the volume of the data won’t exceed the efficient scale of relational database, which is at least of magnitude of tens of gigabytes.
SQLite is the particular relational database management system which is the backbone of PennFS. It has both the ad-vantage of seamless integration with Visual Studio 2012 and the stable performance in data storage. To justify the first reason, because SQLite team has incorporated the SQLite native service interfaces into Visual Studio Extension SDK format, SQLite is currently an integrated service called SQLite for Windows Runtime. This has greatly reduced the work-load in bridging the native SQLite queries and the managed front-end user experience. Moreover, this SQLite extension has provided thoroughly tested interfaces in accessing,
up-dating and removing database contents. Therefore, Pen-nFS obtains correct dependencies for the SQLite database after including the extension. On the other hand, by in-stalling the SQLite Extension, the database interactions can be implemented using C# programming language [4]. This has reduced the backend debugging complexity and, in re-turn, enhances the performance. Additionally, since SQLite database is hosted under the default application execution folder in local filesystem, it maintains a steady performance in real-time modifications. As shown in the Figure 3, the
Figure 3: Entity Relation Diagram
database design contains two entities, FileInfo and Tag, and one relation, Has. To better illustrate the diagram, defini-tions of technical terms are given as follows. Entity-Relation diagram for database describes the data requirements and assumptions in the system from a top-down perspective [1]. In the scope of database management system, Entity means an object that can be uniquely identified. Relation means a relationship that associates one or multiple entities. Prop-erty means an attribute associated with only one entity. A primary key is a set of properties that uniquely identifies one instance from an entity. By default, an entity should have at least one primary key [13].
As mentioned in System Model section, the backend database system stores file metadata. Therefore, it is clear that the database should record file information such as name, time of creation and time of modification. Tag entity is necessary since the backend needs to retain the user-defined tags and associates the tags with different set of files. The Has rela-tion signifies the connecrela-tion between the two entities. Given one tag, Has relation can return a set of file metadata under that tag, while given one file token, Has relation can return a set of tags associated with that file. Hence, the design and implementation of the above system is necessary and sufficient for PennFS.
As the justification of the Entity-Relation diagram has been introduced, the SQLite access interfaces are elaborated here. In particular, the database creation, update and query are established using LINQ, a query language that has exten-sive support for SQLite Windows 8 Runtime. With LINQ, database entity tables are defined using “Table” attribute in its declaration whereas the relation tables are defined using “Association” attribute. Properties of entities are defined as member variables under entity tables. The LINQ queries are described in standard query operators for various entity and relation tables [2].
supports user-defined tagging and searching. The completed interfaces include the following: storing the user-defined tag into SQLite database; retrieving a set of files and folders metadata under a particular tag; searching reversely for the tags associated with a file in the database; Adding and ing a FileInfo instance into the database; Adding and delet-ing a Tag instance into the database.
5.
RESULTS
5.1
Product
Figure 4: Screenshot of PennFS
PennFS, a Windows 8 Store Application, provides a uni-fied view of both the local file system and online email and file storage services. As the Figure. 4, a screenshot of the application indicates, PennFS consist of three major views. On the left is a list of clickable options including Recent Files, Browse Files, Browse Email and Search. In the mid-dle is the view displaying selectable files and emails. On the right is a list of all the tags in the system. Controls are done by using an App bar (Figure. 5)at the bottom of the page.
PennFS users are able to organize their existing local file system and email using tags. Under the browse files option, user is able to create and edit tags by clicking the button on the App bar. Once at least tag is created, user is able to load files belong to the selected tags into the database by clicking the load files button on the App bar. The files loaded would be shown in the middle file display view. To select emails, user can go to the browse email options to tag the emails in the same fashion.
PennFS users are able to search for files according to tags and keyword. Once one or more tags are selected, the users are able to choose to do either a union or intersection opera-tions on the result. If union is chosen, files belong to one or more tags would be shown in file display view. If intersection is chosen, files belong to all tags selected would be shown in the file display view. In addition, if the user enters keywords in the query textbox while selecting tags, a combination of all result matches the query would be displayed.
Figure 5: App Bar of PennFS
5.2
Performance
To test our application, we loaded the folders for the course of this semester’s into the database. There are 279 folders and 3194 files including coding projects files. Also, we tagged them using names of the courses, and add up to 82 tags. For the current data set, our application is able to locate the files with tags efficiently. Traditionally, start-ing from a sstart-ingle root, such as “Fall2012”, locatstart-ing four files from four different folders with an average depths of four would require 16 steps. The number of steps increase as the number of file and depth increase. However with our implementation all the files will be presented in a flat view. The step of locating files in multiple folders is reduced to one single query. This shows that the search experience our system could largely benefit from the tagging with enough organization effort.
6.
FUTURE WORK
Given the flexible database design and user experience, PennFS could be extended in several aspects. First of all, more online file sharing depots could be incorporated. One additional overhead is the configuration on the database. In particular, because of the heterogenenity of metadata from other online depots, database entities should be expanded and corresponding interfaces should be updated. The other overhead is network delay because transferring updates from online depots requires network communication. Currently, Dropbox has a stable third-party API, Spring.NET Social Dropbox, available for Windows Store Application.
Secondly, the email attachments could also be included in the backend database. It is common that a user would use the attachment functionality to store temporary files and thus the inclusion of the attachments would increase the ac-cessability and mobility of PennFS. This functionality could be built upon the existing LimiLab application interface.
Finally, recommendation algorithms could be applied to PennFS so that it could suggest relevant files for a particu-lar tag. This could be built from the active database entries and the Most Recently Accessed list, which is introduced in Section 4.2. However, to ensure that the recommendations are up-to-date in real-time, it requires effort to implement an asynchronous event to execute the recommendation al-gorithm on the database.
7.
ETHICS
PennFS might introduce several ethical issues but they are all amendable in the long run. First of all, since Win-dows 8 allows multiple users sharing the same device with different accounts, PennFS backend storage could introduce an access conflict because all users on the same physical ma-chine would share the same database location. One solution to this issue is that PennFS could utilize the Microsoft Sky-Drive, a Microsoft native file hosting service, to store back-end metadata. In principle, because SkyDrive allows user to files private, the backend access conflict problem could be resolved.
Since PennFS is integrated with Gmail platform, an addi-tional sign-in system should be implemented to ensure the privacy of the user. Windows 8 API has already provided customizable login prototypes which could be utilized to im-plement the sign-in system. To prevent misuse of creden-tials, PennFS is required to directly invoke the sign-in
mod-ule from Windows 8 and would not store the access token from Gmail system. Once the system is in-place, PennFS would just require credentials to be set by the user before providing email accessing functionalities.
8.
CONCLUSION
An alternative file system based on relational database rather than tree structure is successfully built on the top of NTFS filesystem. With a unified view, PennFS allows management and access of files on local filesystem and emails using tags. PennFS simplifies the process of file management and displays the multiple relationships between files using the logic operations between tags.
9.
REFERENCES
[1] Peter Pin-Shan Chen. The entity-relationship mode: toward a unified view of data. ACM Trans. Database Syst., 1(1):9–36, March 1976.
[2] Matt Warren Anders Hejlsberg Kit George Dinesh Kulkarni, Luca Bolognese. Linq to sql: .net language-integrated query for relational data. http:// msdn.microsoft.com/en-us/library/bb425822.aspx, March 2007.
[3] Jim Gary. Greeings! from a filesystem user. 4 th USENIX Conference on File and Storage Technologies, San Francisco, CA, 2005.
[4] Robert Green-MFST. Using sqlite in windows 8 store apps. http:
//blogs.msdn.com/b/robertgreen/archive/2012/ 11/13/using-sqlite-in-windows-store-apps.aspx, November 2011.
[5] Richard Grimes. Winfs lets users search and manage files based on content. http://msdn.microsoft.com/ en-us/magazine/cc164028.aspx, 2004.
[6] Limilabs. http://www.limilabs.com/mail. http://www.limilabs.com/maill.
[7] Sharad Mehrotra, Chun Zhang, Jeffrey Naughton, David DeWitt, Qiong Luo, and Guy Lohman. On supporting containment queries in relational database management systems, pages 425–436. Association for Computing Machinery, 2001.
[8] Microsoft. Blend for visual studio 2012. http://msdn.microsoft.com/en-us/library/ windows/apps/jj129478.aspx, December 2012. [9] Microsoft. Introduction to the c# language and the
.net framework. http://msdn.microsoft.com/en-US/ library/vstudio/z1zx9t92, August 2012.
[10] Microsoft. Windows software development kit (sdk) for windows 8.
WindowsSoftwareDevelopmentKit(SDK)forWindows8, August 2012.
[11] pmengal. Mailsystem.net.
http://mailsystem.codeplex.com, October 2012. [12] Russell Sears, Catherine Van Ingen, and Jim Gary. To
blob or not to blob: Large object storage in a database or a filesystem? In Microsoft Research Technical Report, 2006.
[13] B Thalheim. Entity-relationship modeling :
foundations of database technology. Springer, Berlin New York, 2000.
