I’m trying to work out whether a file system driver is a suitable way of
providing the following facility, or whether other approaches might be
better. I’d welcome some comment from the experienced people on this list!
We make a flat-file database called Cardbox, which (among other things)
allows you to attach objects to each record using OLE. This is good but it
has its limitations. For example: imagine using a database to store emails
- you’d obviously want to store the email’s attachments as attachments to
the database record for that email. But that means making the attachment
into an OLE object… and that in turn means that the application that
eventually opens the attachment has to understand OLE as well. Suppose
that someone sends you a .txt or .qxd attachment: neither Notepad nor
Quark XPress understand OLE, they both want to open a file that exists
somewhere on a real file system.
This is why I thought that a specialised file system driver might provide
a better way forward. I’d imagine things working something like the
following [forgive me if I get some of the specialised vocabulary wrong]:
- The user asks Cardbox to open an attachment.
- Cardbox synthesizes a filename - for instance, B6234267.QXD - and tells
Windows to open it.
- Windows recognises the .QXD extension, and calls Quark XPress with the
filename B6234267.QXD on the command line.
- Quark XPress tries to open B6234267.QXD.
- The Windows file system recognises B6234267.QXD as belonging to the
Cardbox file system driver.
- The Cardbox file system driver recognises the synthetic filename and
permits the “file” to be opened in a read-only mode.
- When Quark tries to read the “file”, Cardbox sends a message to the
database server, waits for the response, and returns the data to Quark.
So here are a few questions to start with:
- Could file system drivers be made to work in this sort of way?
- What would an appropriate filename actually look like?
- Would the filename have to have some sort of existence piggybacked onto
an existing NTFS directory structure, or could it be entirely separate?
(so that the user’s disk doesn’t have to be in NTFS format)
- Would implementing something like this be incredibly complicated - in
other words, are we mad to be thinking of this? Given that we don’t want
to have a navigable directory structure at all, perhaps there is a much
simpler way…
Sorry this is such a long question, but I’m new to all this. Even the
simplest of pointers would be a big help!
For your specific purpose (i.e. recognizing files on an existing
filesystem as ‘special’ and treating them thus in a transparent manner)
you would need a filesystem filter, not a filesystem. But both filters
and filtesystems are extremely complex and time-consuming to develop,
and there are easier ways to accomplish what you want to do.
From what I know of Microsoft Outlook, it too stores emails and
attachments in a monolithic database file of sorts - when you want to
open an attachment, Outlook will save the attachment to a temporary file
on your hard disk, and then launch the temporary file. The temp file
will be deleted when you close the application and switch away from the
current email message.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Kochanski
Sent: Saturday, March 01, 2003 4:00 AM
To: File Systems Developers
Subject: [ntfsd] Embedded files within a database?
I’m trying to work out whether a file system driver is a
suitable way of providing the following facility, or whether
other approaches might be better. I’d welcome some comment
from the experienced people on this list!
We make a flat-file database called Cardbox, which (among
other things) allows you to attach objects to each record
using OLE. This is good but it has its limitations. For
example: imagine using a database to store emails
- you’d obviously want to store the email’s attachments as
attachments to the database record for that email. But that
means making the attachment into an OLE object… and that in
turn means that the application that eventually opens the
attachment has to understand OLE as well. Suppose that
someone sends you a .txt or .qxd attachment: neither Notepad
nor Quark XPress understand OLE, they both want to open a
file that exists somewhere on a real file system.
This is why I thought that a specialised file system driver
might provide a better way forward. I’d imagine things
working something like the following [forgive me if I get
some of the specialised vocabulary wrong]:
- The user asks Cardbox to open an attachment.
- Cardbox synthesizes a filename - for instance,
B6234267.QXD - and tells Windows to open it. 3. Windows
recognises the .QXD extension, and calls Quark XPress with
the filename B6234267.QXD on the command line. 4. Quark
XPress tries to open B6234267.QXD. 5. The Windows file system
recognises B6234267.QXD as belonging to the Cardbox file
system driver. 6. The Cardbox file system driver recognises
the synthetic filename and permits the “file” to be opened in
a read-only mode. 7. When Quark tries to read the “file”,
Cardbox sends a message to the database server, waits for the
response, and returns the data to Quark.
So here are a few questions to start with:
- Could file system drivers be made to work in this sort of way?
- What would an appropriate filename actually look like?
- Would the filename have to have some sort of existence
piggybacked onto an existing NTFS directory structure, or
could it be entirely separate? (so that the user’s disk
doesn’t have to be in NTFS format)
- Would implementing something like this be incredibly
complicated - in other words, are we mad to be thinking of
this? Given that we don’t want to have a navigable directory
structure at all, perhaps there is a much simpler way…
Sorry this is such a long question, but I’m new to all this.
Even the simplest of pointers would be a big help!
You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> For your specific purpose (i.e. recognizing files on an existing
filesystem as ‘special’ and treating them thus in a transparent manner)
you would need a filesystem filter, not a filesystem. But both filters
and filtesystems are extremely complex and time-consuming to develop,
and there are easier ways to accomplish what you want to do.
Actually the “special” files won’t necessarily be files at all: they may
be just a range of bytes within a file held on some remote server. But
that simply makes your point even more cogent!
From what I know of Microsoft Outlook, it too stores emails and
attachments in a monolithic database file of sorts - when you want to
open an attachment, Outlook will save the attachment to a temporary file
on your hard disk, and then launch the temporary file. The temp file
will be deleted when you close the application and switch away from the
current email message.
Thank you for the advice: this looks to be one area where it is simply not
worth trying to do better than Microsoft… quite apart from the
development effort in creating the filter in the first place, the support
issues could be horrendous.
> - Would implementing something like this be incredibly complicated -
in
other words, are we mad to be thinking of this? Given that we don’t
want
Yes it will (it will need a full-blown FSD), though here at
StorageCraft we have a framework for sale which can do this for you.
Max