I’m curious, what are the alternative methods (other than NT FSDs) of expose
a filesystem in Windows NT/2000/XP? For example, using a DOS IFS in a DOS
box. Is it possible? What else is possible?
Thanks,
- Jeremy
- What is a DOS IFS? DOS included some INT 2Fh and INT 2Ah stuff for
redirector support but didn’t provide an installable file system
architecture that I know of. - Are you implying that you would load something in user mode and
perform block i/o through block device ioctl’s? You might be able to
write some kind of thing like that in user mode - but why would you? It
would only be available to the user mode process that loads it and then
how would you load other applications to use it? Seems senseless. - Wouldn’t you want the WIN32 and possibly other file system interfaces
to work with it? If so, then you it would have to work with the I/O
subsystem in kernel mode and hence have to be a kernel mode device
driver - and an NT FSD to act like a file system.
Anything is possible. But I don’t think in this case it is sensible.
/TomH
-----Original Message-----
From: Jeremy Sherrill [mailto:xxxxx@datalight.com]
Sent: Wednesday, July 07, 2004 8:40 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Alternative FS interfaces on NT/2000/XP
I’m curious, what are the alternative methods (other than NT FSDs) of
expose
a filesystem in Windows NT/2000/XP? For example, using a DOS IFS in a
DOS
box. Is it possible? What else is possible?
Thanks,
- Jeremy
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@exagrid.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Yes, DOS has an IFS architecture, and it’s as quirky as an IFS interface
could be. MSCDEX.EXE was a DOS IFS. To keep the conversation productive,
I’ll rephrase my question:
What would you do, if you were a file system vendor, selling a proprietary
file system to OEMs, and needed to offer SOME means of transferring data
from removable media (formatted with your FS) to a Windows based system?
Of course, a fully functional and compatible NT FSD is by far the best means
of doing this. However, that’s no simple thing. So, since an FSD is such a
complex driver and can take quite some time to develop and test, it would be
best to offer customers SOME means of reading disks in the meantime. That
is the motivation. Can anyone suggest some options?
Thanks,
Jeremy
“Tom Hansen” wrote in message news:xxxxx@ntfsd…
- What is a DOS IFS? DOS included some INT 2Fh and INT 2Ah stuff for
redirector support but didn’t provide an installable file system
architecture that I know of.
- Are you implying that you would load something in user mode and
perform block i/o through block device ioctl’s? You might be able to
write some kind of thing like that in user mode - but why would you? It
would only be available to the user mode process that loads it and then
how would you load other applications to use it? Seems senseless.
- Wouldn’t you want the WIN32 and possibly other file system interfaces
to work with it? If so, then you it would have to work with the I/O
subsystem in kernel mode and hence have to be a kernel mode device
driver - and an NT FSD to act like a file system.
Anything is possible. But I don’t think in this case it is sensible.
/TomH
-----Original Message-----
From: Jeremy Sherrill [mailto:xxxxx@datalight.com]
Sent: Wednesday, July 07, 2004 8:40 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Alternative FS interfaces on NT/2000/XP
I’m curious, what are the alternative methods (other than NT FSDs) of
expose
a filesystem in Windows NT/2000/XP? For example, using a DOS IFS in a
DOS
box. Is it possible? What else is possible?
Thanks,
- Jeremy
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@exagrid.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
If I only needed to transfer the data, I would be tempted
to go with a user mode program using raw read against the
device to copy the files off the media.
- You get to use C++ / Java / C# / V-Basic / whatever
running in an IDE. - You get to use the debugger of your choice, running
on the same machine, and you don’t have to reboot between
bug fixes (which tends to slow down the code / test / fix
cycle just a tad.) - If you miss a bug, you didn’t just crash your customer’s
machine potential losing data and causing other nasty
headaches. - If you miss a bug with security implications you didn’t
expose your customer’s data to bad guys.
- Joseph
Jeremy Sherrill wrote:
Yes, DOS has an IFS architecture, and it’s as quirky as an IFS interface
could be. MSCDEX.EXE was a DOS IFS. To keep the conversation productive,
I’ll rephrase my question:What would you do, if you were a file system vendor, selling a proprietary
file system to OEMs, and needed to offer SOME means of transferring data
from removable media (formatted with your FS) to a Windows based system?Of course, a fully functional and compatible NT FSD is by far the best means
of doing this. However, that’s no simple thing. So, since an FSD is such a
complex driver and can take quite some time to develop and test, it would be
best to offer customers SOME means of reading disks in the meantime. That
is the motivation. Can anyone suggest some options?Thanks,
Jeremy“Tom Hansen” wrote in message news:xxxxx@ntfsd…
> - What is a DOS IFS? DOS included some INT 2Fh and INT 2Ah stuff for
> redirector support but didn’t provide an installable file system
> architecture that I know of.
> - Are you implying that you would load something in user mode and
> perform block i/o through block device ioctl’s? You might be able to
> write some kind of thing like that in user mode - but why would you? It
> would only be available to the user mode process that loads it and then
> how would you load other applications to use it? Seems senseless.
> - Wouldn’t you want the WIN32 and possibly other file system interfaces
> to work with it? If so, then you it would have to work with the I/O
> subsystem in kernel mode and hence have to be a kernel mode device
> driver - and an NT FSD to act like a file system.
>
> Anything is possible. But I don’t think in this case it is sensible.
>
> /TomH
>
> -----Original Message-----
> From: Jeremy Sherrill [mailto:xxxxx@datalight.com]
> Sent: Wednesday, July 07, 2004 8:40 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Alternative FS interfaces on NT/2000/XP
>
> I’m curious, what are the alternative methods (other than NT FSDs) of
> expose
> a filesystem in Windows NT/2000/XP? For example, using a DOS IFS in a
> DOS
> box. Is it possible? What else is possible?
>
> Thanks,
> - Jeremy
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@exagrid.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@vandyke.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Jeremy,
I can think of one approach, I have not tried this, but may be it is a good intermediate solution before a complete FSD is developed to understand and expose the propritory File system residing on a removable media.
In Windows Explorer, you can write a ‘Namespace Extension’ which allows you to add a completely independent Namespace tree consisting of container and leaf objects.
The code that presents this tree is completly in the user space and is in the form of a COM object. If you implement this COM object such that it reads the raw device containing your propripory File System, you can show the contents of your File System in the explorer with full read and write access. As far as I know, I don’t think explorer invokes normal File System APIs when traversing through the object residing in this name space tree. Folks, correct me if I am wrong here.
For example, my bluetooth cell phone software addes a namespace extension which appears as ‘My P800’ and anything below it appears as normal namespace tree. When I traverse through this tree the contents are actually obtained from my cell phone memory.
I have implemented a namespace extension in the past, but not to expose a full namespace tree, so this approach may not work.
What do you think folks?
Regards,
Manish
Jeremy Sherrill wrote:
Yes, DOS has an IFS architecture, and it’s as quirky as an IFS interface
could be. MSCDEX.EXE was a DOS IFS. To keep the conversation productive,
I’ll rephrase my question:
What would you do, if you were a file system vendor, selling a proprietary
file system to OEMs, and needed to offer SOME means of transferring data
from removable media (formatted with your FS) to a Windows based system?
Of course, a fully functional and compatible NT FSD is by far the best means
of doing this. However, that’s no simple thing. So, since an FSD is such a
complex driver and can take quite some time to develop and test, it would be
best to offer customers SOME means of reading disks in the meantime. That
is the motivation. Can anyone suggest some options?
Thanks,
Jeremy
“Tom Hansen” wrote in message news:xxxxx@ntfsd…
- What is a DOS IFS? DOS included some INT 2Fh and INT 2Ah stuff for
redirector support but didn’t provide an installable file system
architecture that I know of.
- Are you implying that you would load something in user mode and
perform block i/o through block device ioctl’s? You might be able to
write some kind of thing like that in user mode - but why would you? It
would only be available to the user mode process that loads it and then
how would you load other applications to use it? Seems senseless.
- Wouldn’t you want the WIN32 and possibly other file system interfaces
to work with it? If so, then you it would have to work with the I/O
subsystem in kernel mode and hence have to be a kernel mode device
driver - and an NT FSD to act like a file system.
Anything is possible. But I don’t think in this case it is sensible.
/TomH
-----Original Message-----
From: Jeremy Sherrill [mailto:xxxxx@datalight.com]
Sent: Wednesday, July 07, 2004 8:40 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Alternative FS interfaces on NT/2000/XP
I’m curious, what are the alternative methods (other than NT FSDs) of
expose
a filesystem in Windows NT/2000/XP? For example, using a DOS IFS in a
DOS
box. Is it possible? What else is possible?
Thanks,
- Jeremy
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@exagrid.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
Manish,
I think Ur stmt about not going thru file systems is not true !. I did once do a complete name extension, well of course starting from a good example, but the call backs that explorer uses are CShell* based class, and IIRC they have FS interface. If you happen to have one it is easy to test under a krnl debugger to find it out 
-pro
“Jeremy Sherrill” wrote in message
news:xxxxx@ntfsd…
> Of course, a fully functional and compatible NT FSD is by far the best
means
> of doing this. However, that’s no simple thing. So, since an FSD is such
a
> complex driver and can take quite some time to develop and test, it would
be
> best to offer customers SOME means of reading disks in the meantime. That
> is the motivation. Can anyone suggest some options?
>
Well a several suggestions come to mind:
1. If you can afford it get the OSR File System Development Kit
http://www.osr.com/toolkits_fsdk.shtml this will give allow you to get a
fully functional driver quicker.
2. A temporary (ok maybe permenant solution) is to use StorageCraft’s
User-Mode File System http://www.storagecraft.com/products/umfs.html
3, An even cheaper (though more temporary) solution would be get a copy of
Samba and put you disk access in as the file system access, and have the
users access the disk via a network drive.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
When you say file system, it implies to me that this is something that
would allow an application to access files through standard APIs. If
you need to read media that is in some proprietary format on Windows,
then you could certainly write something in user mode that accesses the
device through some lower level driver - such as a the block device.
The DOS emulation in Windows NT/2000/2003 does not support a device
driver that performs low level device access - such as is often the case
with these DOS device drivers - such as MSCDEX - which if I remember
correctly would ride on top of the CD block device driver, such as those
provided by ADAPTEC (ASPI) and APAPI vendors. I don’t believe there any
realistic chance of getting this to work. This was one of the reasons
that a lot of games didn’t run on the NT kernel but did work on Windows
95.
Anyway, you got a lot of responses and suggestions.
/TomH
-----Original Message-----
From: Jeremy Sherrill [mailto:xxxxx@datalight.com]
Sent: Thursday, July 08, 2004 6:40 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Alternative FS interfaces on NT/2000/XP
Yes, DOS has an IFS architecture, and it’s as quirky as an IFS interface
could be. MSCDEX.EXE was a DOS IFS. To keep the conversation
productive,
I’ll rephrase my question:
What would you do, if you were a file system vendor, selling a
proprietary
file system to OEMs, and needed to offer SOME means of transferring data
from removable media (formatted with your FS) to a Windows based system?
Of course, a fully functional and compatible NT FSD is by far the best
means
of doing this. However, that’s no simple thing. So, since an FSD is
such a
complex driver and can take quite some time to develop and test, it
would be
best to offer customers SOME means of reading disks in the meantime.
That
is the motivation. Can anyone suggest some options?
Thanks,
Jeremy
“Tom Hansen” wrote in message news:xxxxx@ntfsd…
- What is a DOS IFS? DOS included some INT 2Fh and INT 2Ah stuff for
redirector support but didn’t provide an installable file system
architecture that I know of.
- Are you implying that you would load something in user mode and
perform block i/o through block device ioctl’s? You might be able to
write some kind of thing like that in user mode - but why would you? It
would only be available to the user mode process that loads it and then
how would you load other applications to use it? Seems senseless.
- Wouldn’t you want the WIN32 and possibly other file system interfaces
to work with it? If so, then you it would have to work with the I/O
subsystem in kernel mode and hence have to be a kernel mode device
driver - and an NT FSD to act like a file system.
Anything is possible. But I don’t think in this case it is sensible.
/TomH
-----Original Message-----
From: Jeremy Sherrill [mailto:xxxxx@datalight.com]
Sent: Wednesday, July 07, 2004 8:40 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Alternative FS interfaces on NT/2000/XP
I’m curious, what are the alternative methods (other than NT FSDs) of
expose
a filesystem in Windows NT/2000/XP? For example, using a DOS IFS in a
DOS
box. Is it possible? What else is possible?
Thanks,
- Jeremy
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@exagrid.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@exagrid.com
To unsubscribe send a blank email to xxxxx@lists.osr.com