Hello people, this is my very first message to this forum. Well, I’m developing a minifilter driver to notify from times to times the list of files that have being changed. I’ve openned and changed the source of filespy demo. The demo .SYS and .EXE are working pretty nice.
The problem is that I want to replicate the user .EXE functionality but using borland Delphi. I’ve already translated the user unit headers from C to Delphi. Everything is suposed to be OK till now. The problem starts now:
On the first attempt, I tryied calling FilterConnectCommunicationPort() with no success. And this is exactly what the demo .EXE does, and works. The difference on the demo EXE and my EXE is that for some reason that I want to know why, I must do a “net start minispy” before openning the demo exe. Otherwise it doesn’t work. Now I need to know why? Why do I need to do a “net start” before? What does a service has to do with all this? Why does this minifilter process needs a service? What does exactly this service do? I’ve looked into the demo exe source and I didn’t find anything about services. Can someone help me figuring this out?
Thanks very mutch!
Ouc,… My mistake. “\” is C is actually "" in Delphi. Oooops
If you just need to track when files change, have you looked at whether change notifications or the NTFS USN journal would suit your needs adequately before you go down the filter route?
-----Original Message-----
From: xxxxx@gmail.com
Sent: Saturday, June 06, 2009 06:42
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Minifilter: How to start?
Hello people, this is my very first message to this forum. Well, I’m developing a minifilter driver to notify from times to times the list of files that have being changed. I’ve openned and changed the source of filespy demo. The demo .SYS and .EXE are working pretty nice.
The problem is that I want to replicate the user .EXE functionality but using borland Delphi. I’ve already translated the user unit headers from C to Delphi. Everything is suposed to be OK till now. The problem starts now:
On the first attempt, I tryied calling FilterConnectCommunicationPort() with no success. And this is exactly what the demo .EXE does, and works. The difference on the demo EXE and my EXE is that for some reason that I want to know why, I must do a “net start minispy” before openning the demo exe. Otherwise it doesn’t work. Now I need to know why? Why do I need to do a “net start” before? What does a service has to do with all this? Why does this minifilter process needs a service? What does exactly this service do? I’ve looked into the demo exe source and I didn’t find anything about services. Can someone help me figuring this out?
Thanks very mutch!
—
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I would build a helper DLL using WDK which will wrap the FltMgr’s APIs to some form of your own.
Then call this DLL from Delphi.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntfsd…
> Hello people, this is my very first message to this forum. Well, I’m developing a minifilter driver to notify from times to times the list of files that have being changed. I’ve openned and changed the source of filespy demo. The demo .SYS and .EXE are working pretty nice.
>
> The problem is that I want to replicate the user .EXE functionality but using borland Delphi. I’ve already translated the user unit headers from C to Delphi. Everything is suposed to be OK till now. The problem starts now:
>
> On the first attempt, I tryied calling FilterConnectCommunicationPort() with no success. And this is exactly what the demo .EXE does, and works. The difference on the demo EXE and my EXE is that for some reason that I want to know why, I must do a “net start minispy” before openning the demo exe. Otherwise it doesn’t work. Now I need to know why? Why do I need to do a “net start” before? What does a service has to do with all this? Why does this minifilter process needs a service? What does exactly this service do? I’ve looked into the demo exe source and I didn’t find anything about services. Can someone help me figuring this out?
>
> Thanks very mutch!
>
Net start loads the driver, you will need to have the driver loaded to
communicate with it. The right way for the minispy sample is with the fltmc
utility as explained in the documentation. You can avoid these steps and do
this yourself by calling FilterCreate from your app.
Note that if you only need to know what files change you can also get this
information without going into the kernel from USN journals as well with ETW
tracing.
//Daniel
wrote in message news:xxxxx@ntfsd…
> On the first attempt, I tryied calling FilterConnectCommunicationPort()
> with no success. And this is exactly what the demo .EXE does, and works.
> The difference on the demo EXE and my EXE is that for some reason that I
> want to know why, I must do a “net start minispy” before openning the demo
> exe. Otherwise it doesn’t work. Now I need to know why? Why do I need to
> do a “net start” before? What does a service has to do with all this? Why
> does this minifilter process needs a service? What does exactly this
> service do? I’ve looked into the demo exe source and I didn’t find
> anything about services. Can someone help me figuring this out?
>
@SkyWing: I’ve tryied the FileChangeNotification resource from Windows APIs,
but it needs to open a handle on a directory. Then, if i want to have
notifications on a Pendrive for example this pendrive won’t never be
securily removed trough trayicon’s right click.
@SkyWing and Daniel: Does USN journals and ETW tracing catches changes even
on FAT systems?
I was finally able to connect to my filter driver! But if USN journals and
ETW tracing is better and more stable then I would like to proceed that way,
if works on FAT systems as well
Thanks
On Sat, Jun 6, 2009 at 5:47 PM, wrote:
> Net start loads the driver, you will need to have the driver loaded to
> communicate with it. The right way for the minispy sample is with the fltmc
> utility as explained in the documentation. You can avoid these steps and do
> this yourself by calling FilterCreate from your app.
>
> Note that if you only need to know what files change you can also get this
> information without going into the kernel from USN journals as well with ETW
> tracing.
>
> //Daniel
>
>
> wrote in message news:xxxxx@ntfsd…
>
>> On the first attempt, I tryied calling FilterConnectCommunicationPort()
>> with no success. And this is exactly what the demo .EXE does, and works. The
>> difference on the demo EXE and my EXE is that for some reason that I want to
>> know why, I must do a “net start minispy” before openning the demo exe.
>> Otherwise it doesn’t work. Now I need to know why? Why do I need to do a
>> “net start” before? What does a service has to do with all this? Why does
>> this minifilter process needs a service? What does exactly this service do?
>> I’ve looked into the demo exe source and I didn’t find anything about
>> services. Can someone help me figuring this out?
>>
>>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
's
Bruno Martins Stuani
The USN journal is a NTFS feature so it won’t work on FAT.
Possibly ETW tracing for file operations also works on file systems other
than NTFS, I suppose the only way is to try. In any case it only works on
Vista and higher. I don’t recommend using this technology but I wanted you
to be aware of its existence as developing a file system filter requires a
lot of knowledge and experience.
//Daniel
“Bruno Stuani” wrote in message news:xxxxx@ntfsd…
@SkyWing and Daniel: Does USN journals and ETW tracing catches changes even
on FAT systems?
I was finally able to connect to my filter driver! But if USN journals and
ETW tracing is better and more stable then I would like to proceed that way,
if works on FAT systems as well
Got it! Thanks for the helpfull information. I hope I get a lot of
experience by managing with drivers
On Sun, Jun 7, 2009 at 12:35 PM, wrote:
> The USN journal is a NTFS feature so it won’t work on FAT.
>
> Possibly ETW tracing for file operations also works on file systems other
> than NTFS, I suppose the only way is to try. In any case it only works on
> Vista and higher. I don’t recommend using this technology but I wanted you
> to be aware of its existence as developing a file system filter requires a
> lot of knowledge and experience.
>
> //Daniel
>
>
> “Bruno Stuani” wrote in message news:xxxxx@ntfsd…
>>
> @SkyWing and Daniel: Does USN journals and ETW tracing catches changes even
> on FAT systems?
>
> I was finally able to connect to my filter driver! But if USN journals and
> ETW tracing is better and more stable then I would like to proceed that way,
> if works on FAT systems as well
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
's
Bruno Martins Stuani
On Sat, 6 Jun 2009, xxxxx@gmail.com wrote:
Hello people, this is my very first message to this forum. Well, I’m
developing a minifilter driver to notify from times to times the list of
files that have being changed. I’ve openned and changed the source of
filespy demo. The demo .SYS and .EXE are working pretty nice.
I’ve done a couple of related projects, including using delphi, so I’ll
pass on what I found.
First, I think your project could all be done using Win32 without needing
a driver. The only problems would having to hook the messages indicating
a drive has arrived in order to set the change notificaation flag for that
drive.
ALso, if you go the driver route, I wouldn’t recommend using delphi for
the driver. There would bound to be something you didn’t convert right in
the many headers. And also, it’s only a 32 bit compiler, which can’t
compile for 64 bit OSes.
I know someone who uses his own 64 bit delphi compatible compiler (I’m not
running an ad for it here), but I don’t know how much effort he had to put
into it to make it work. Hardly something I’d call a reasonable challenge
for your first driver.
Erick
Note that fltuser.h consists only of a few function declarations and not
much more, there is not much translation needed to get the usermode part of
the filtermanager API going on Delphi. You don’t necessarily need a native
x64 application, 32 bit (Delphi) applications can communicate well with 64
bit minifilters and other drivers.
//Daniel
“Erick Engelke” wrote in message
news:xxxxx@ntfsd…
ALso, if you go the driver route, I wouldn’t recommend using delphi for
> the driver. There would bound to be something you didn’t convert right in
> the many headers.
…
>And also, it’s only a 32 bit compiler, which can’t compile for 64 bit
>OSes.
> I know someone who uses his own 64 bit delphi compatible compiler (I’m not
> running an ad for it here), but I don’t know how much effort he had to put
> into it to make it work. Hardly something I’d call a reasonable challenge
> for your first driver.
>