Thank you all for your replies. Here’s a bit more info on what I’m trying
to do.
- I want to be able to expose the contents of my “archive” so that it
appears in explorer (and thus through file-open dialogs done by various
applications).
- I want to handle open/read/position/… calls to provide the desired
content. Our customer wants to put upwards of 1 Gb files into our archive
and not have to pull it out to local storage before it can be opened.
- I have no need to make updates to the archive (and in fact it would
typically be hard to do so since it will often be on read-only media.)
- I need to support Windows 95, 98, Me, NT (probably on 4.x), 2000, and
XP.
So, from my quick look at the docs, it appears that a shell extension
can’t satisfy this requirement. Please correct me if I’m wrong about
this.
So, can a filesystem filter driver satify these requirement? If so, do
you have suggestions on where to start my research?
Thanks again,
Dave
If you can’t pull it out to local storage before opening it, then I
don’t know of any way to do this without implementing a full-fledged
filesystem (a filter isn’t enough for this purpose). An application
needs a pathname to open a file, and if you can’t feed it a path to a
file on the existing filesystem, then you need to feed it a path to a
file on your filesystem.
As others have said you’re looking at an expensive and time-consuming
project (especially considering that you must support 9x and NT4 as
well).
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David A. Myers
Sent: Friday, September 20, 2002 2:22 PM
To: File Systems Developers
Subject: [ntfsd] Further questions about file-based file systems
Thank you all for your replies. Here’s a bit more info on
what I’m trying to do.
- I want to be able to expose the contents of my “archive”
so that it appears in explorer (and thus through file-open
dialogs done by various applications). 2. I want to handle
open/read/position/… calls to provide the desired content.
Our customer wants to put upwards of 1 Gb files into our
archive and not have to pull it out to local storage before
it can be opened. 3. I have no need to make updates to the
archive (and in fact it would typically be hard to do so
since it will often be on read-only media.) 4. I need to
support Windows 95, 98, Me, NT (probably on 4.x), 2000, and XP.
So, from my quick look at the docs, it appears that a shell
extension can’t satisfy this requirement. Please correct me
if I’m wrong about this.
So, can a filesystem filter driver satify these requirement?
If so, do you have suggestions on where to start my research?
Thanks again,
Dave
You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to %%email.unsub%%
There is another approach that will work on NT4, W2K, & probably XP. I once
wrote a driver for a floppy based SmartMedia reader/writer that used VoiceIt
formatted SmartMedia cards. It mounted them as read only. The real format
of the media was not the FAT format used by digital cameras, but somewhat
similar. I generated an in memory FAT file system for the media. I could
generate a root directory, FAT, and boot record. It worked rather well to
read data from the media.
You are really doing a filesystem, but it is done at the disk device driver
level. The real FAT system mounts it and if you respond to the queries
about being read only correctly, it works very well. This was actually done
in a filter driver that sat above the floppy driver. The same code could be
used on 9x as well because the code specific to SmartMedia was able to run
on both 9x & NT4. The outer driver had to handle the OS differences to
actually read the data from the FlashPath.
----- Original Message -----
From: “Nicholas Ryan”
To: “File Systems Developers”
Sent: Friday, September 20, 2002 5:54 PM
Subject: [ntfsd] RE: Further questions about file-based file systems
> If you can’t pull it out to local storage before opening it, then I
> don’t know of any way to do this without implementing a full-fledged
> filesystem (a filter isn’t enough for this purpose). An application
> needs a pathname to open a file, and if you can’t feed it a path to a
> file on the existing filesystem, then you need to feed it a path to a
> file on your filesystem.
>
> As others have said you’re looking at an expensive and time-consuming
> project (especially considering that you must support 9x and NT4 as
> well).
>
> - Nicholas Ryan
>
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of David A. Myers
> > Sent: Friday, September 20, 2002 2:22 PM
> > To: File Systems Developers
> > Subject: [ntfsd] Further questions about file-based file systems
> >
> >
> > Thank you all for your replies. Here’s a bit more info on
> > what I’m trying to do.
> >
> > 1. I want to be able to expose the contents of my “archive”
> > so that it appears in explorer (and thus through file-open
> > dialogs done by various applications). 2. I want to handle
> > open/read/position/… calls to provide the desired content.
> > Our customer wants to put upwards of 1 Gb files into our
> > archive and not have to pull it out to local storage before
> > it can be opened. 3. I have no need to make updates to the
> > archive (and in fact it would typically be hard to do so
> > since it will often be on read-only media.) 4. I need to
> > support Windows 95, 98, Me, NT (probably on 4.x), 2000, and XP.
> >
> > So, from my quick look at the docs, it appears that a shell
> > extension can’t satisfy this requirement. Please correct me
> > if I’m wrong about this.
> >
> > So, can a filesystem filter driver satify these requirement?
> > If so, do you have suggestions on where to start my research?
> >
> > Thanks again,
> > Dave
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@nryan.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to %%email.unsub%%
>