Introduction
Some time ago, I was sent to work with an old mainframe system. There I became familiar with a source repository where a single file on the system contains several files from the source code. Although this seems very familiar to many people (through TAR or ZIP files), I wanted the ability to work with the files within without copying them to a temporary location. This article is the result of this quest.
The Archive Class
I would be very unpractical to create such a class just to store files. It would work just like many other compression libraries out there – except for no compression at all. Plus, it would impose many limitations to store just files and no directories to organize them.
I created a simple file system based on what has been described as WinFS (Windows Longhorn FileSystem based on SQL). A single file contains a table with every file or folder inside the Archive. It's a simple record, so there's nothing more than a name, number of parent folder, entry points for files, or indexes for folders. I chose to record no dates or times. I also chose to use UNIX-style path separator to avoid escaped backslashes or verbatim strings.
In the end, it's a very simple class containing many of the functionality provided by File
and Directory
classes in the System.IO
namespace, including methods like OpenRead
and OpenText
.
Why would I use it?
At first sight, many would consider a waste of time to use an Archive. And maybe you're right. The usage of every piece of technology depends on its need within the project. Maybe it's not your case.
At first, I designed an Archive to contain source codes for all of my projects. When it was near completion, I realized it wasn't such a great idea but found other uses for it such as small databases (specially to store serialized objects) and/or files I don't want users picking at. You can even find others I haven't thought of, let us know.
Limitations
As far as I can see, there are very few limits to expose:
- An
Int32
is used to index file blocks, so the archive size limit is 1,5Kb * 2,147,483,647 (= 3,221,225,470 Kb, theoretically). This is also the biggest a single file can get. - Directories differ from files by using negative start indexes, thus limiting an Archive to 2,147,483,648 directories. Currently, a stored index is used to retrieve the index for a new directory and this is never reset. (Should I revise it?)
- Maybe others that I can't remember right now.
Expanded Universe
This is the goal of open-source, isn't it? So, the Archive
class is made easy to understand, maintain and modify. In a few minutes reading the code, you'll be able to expand the class personalizing it to your own needs. Here are some examples that can be easily accomplished:
- Replace the "Archive:" header for a more complex version detailing the use or meaning of the files within;
- Simple scramble cryptography – OK, to use a crypto-stream, the file would require a temporary stream, but some simple cryptography (i.e., using
XOR
) is easy; - Additional file information like creation and modification times (which I chose not to include);
- A new property to define which character is to be used for path separation;
- etc.
Some of the modifications might even be useful to other users, so I suggest if you modify the Archive
class, post a brief of the modifications you made here too.
Points of Interest
The code has been widely tested, except for files (as can be seen in the Main
procedure), although the code used was tested in a previous version. So, there should be no problems with it. If there are any problems, let me know.
Also, the Archive
class uses widely .NET Generic collections, limiting its use to .NET Framework 2.0. If anyone is interested in porting it to prior versions, I can post the results here.