DASD I/O

Hi,

In our encryption filter, we sometimes observe IRP_MJ_WRITEs
whose FileObject->FileName.Buffer are NULL that are called DASD I/O
in Filemon.
We have the following problem about DASD I/O.
When a file is modified by Notepad.exe, our filter sometimes catches
no IRP_MJ_WRITEs which have the file name and catches only DASD I/O
write requests instead. So we can’t have the chance to encrypt
written data because our filter can’t get the file object’s file name.
In DASD I/O, we can’t even roll our own IRPs to get the file name.
Are there any ways to get the file name?
Or are there any ways to stop DASD I/O?

Any help is greately appreciated.
Thanks in advance.

Takashi.

It is important that you understand how Windows NT/2000 file systems
actually work with respect to the virtual memory system and for that I would
suggest reading the various postings on this mailing list, the O’Reilly book
on file systems, and my file systems course, because they all discuss this
issue at considerable length.

A file that is modified via a memory mapping (which is how Notepad works in
Windows 2000) writes its changes back to the underlying FSD via paging I/O
operations, because the application modified an in-memory copy of the file.
That in-memory copy is, in turn, the same copy that is maintained for the
file system data cache. Thus, modifications by the application are
immeditely reflected in the file system data cache.

Normally, a file system tracks the interested files, not based upon the name
of the file, but upon the file for which the operation is requested. This
is particularly important for NTFS, because the NTFS file system makes heavy
use of internally created file objects (see IoCreateStreamFileObject and
IoCreateStreamFileObjectLite in the IFS Kit.) These file objects represent
the same file (you can tell this is the case by using the
FileObject->FsContext value to compare two file objects) and thus you must
identify these new file objects so that you may operate on them correctly.

There is no way to stop DASD I/O, nor is querying the file system during the
IRP_MJ_WRITE (with the IRP_PAGING_IO bit) an option because of the
restrictions you must observe while handling paging I/O (you may not access
any pageable code paths within the underlying file system.)

I hope this helps.

Regards,

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@itg.hitachi.co.jp [mailto:xxxxx@itg.hitachi.co.jp]
Sent: Monday, October 16, 2000 1:28 AM
To: File Systems Developers
Subject: [ntfsd] DASD I/O
Sensitivity: Personal

Hi,

In our encryption filter, we sometimes observe IRP_MJ_WRITEs
whose FileObject->FileName.Buffer are NULL that are called DASD I/O
in Filemon.
We have the following problem about DASD I/O.
When a file is modified by Notepad.exe, our filter sometimes catches
no IRP_MJ_WRITEs which have the file name and catches only DASD I/O
write requests instead. So we can’t have the chance to encrypt
written data because our filter can’t get the file object’s file name.
In DASD I/O, we can’t even roll our own IRPs to get the file name.
Are there any ways to get the file name?
Or are there any ways to stop DASD I/O?

Any help is greately appreciated.
Thanks in advance.

Takashi.

DASD stands for Direct Access to Storage Device.

I mean your rules are not complete.
FileObject should be considered for DASD Open
(in FSD this type is called UserVolumeOpen)
only and only if these rules are all true:

  1. The FileObject->FileName.Length == 0
  2. The FileObject->RelatedFileObject == NULL or
    The FileObject->RelatedFileObject->FileName.Length == 0

NOTE:
If RelatedFileObject is non-NULL you should better check
its name by issuing IRP_MJ_QUERY_INFORMATION with the class
FileNameInformation to the FSD.
Only if the returned name has Length of zero it is opened volume (DASD).

Hope this helps
Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@itg.hitachi.co.jp
Sent: Monday, October 16, 2000 7:28 AM
To: File Systems Developers
Subject: [ntfsd] DASD I/O
Sensitivity: Personal

Hi,

In our encryption filter, we sometimes observe IRP_MJ_WRITEs
whose FileObject->FileName.Buffer are NULL that are called DASD I/O
in Filemon.
We have the following problem about DASD I/O.
When a file is modified by Notepad.exe, our filter sometimes catches
no IRP_MJ_WRITEs which have the file name and catches only DASD I/O
write requests instead. So we can’t have the chance to encrypt
written data because our filter can’t get the file object’s file name.
In DASD I/O, we can’t even roll our own IRPs to get the file name.
Are there any ways to get the file name?
Or are there any ways to stop DASD I/O?

Any help is greately appreciated.
Thanks in advance.

Takashi.

> Hi,

In our encryption filter, we sometimes observe IRP_MJ_WRITEs
whose FileObject->FileName.Buffer are NULL that are called DASD I/O
in Filemon.
We have the following problem about DASD I/O.
When a file is modified by Notepad.exe, our filter sometimes catches
no IRP_MJ_WRITEs which have the file name and catches only DASD I/O
write requests instead. So we can’t have the chance to encrypt
written data because our filter can’t get the file object’s file name.

Relying on FileObject->FileName.Buffer is a bad idea.
This string is guaranteed to be valid only during MJ_CREATE handling. FSD is
allowed to destroy it in its MJ_CREATE path.
NTFS actually does this.

Max

Hi,

which is the best way to identify the object (the file)? Is there another
identifier ?

Thank you.

Igor Rosenberg
xxxxx@taureus.sk

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: 17. oktobra 2000 13:53
To: File Systems Developers
Subject: [ntfsd] Re: DASD I/O

Hi,

In our encryption filter, we sometimes observe IRP_MJ_WRITEs
whose FileObject->FileName.Buffer are NULL that are called DASD I/O
in Filemon.
We have the following problem about DASD I/O.
When a file is modified by Notepad.exe, our filter sometimes catches
no IRP_MJ_WRITEs which have the file name and catches only DASD I/O
write requests instead. So we can’t have the chance to encrypt
written data because our filter can’t get the file object’s file name.

Relying on FileObject->FileName.Buffer is a bad idea.
This string is guaranteed to be valid only during MJ_CREATE handling. FSD is
allowed to destroy it in its MJ_CREATE path.
NTFS actually does this.

Max


You are currently subscribed to ntfsd as: xxxxx@taureus.sk
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

Thank you for your replies.
As Tony wrote, we could get over the DASD I/O problem
by using the FileObject->FsContext value to compare two
file objects.

Thanks again for your time and assistance,

Regards,

Takashi

Hello,

so on IRP_MJ_CREATE I have to store FileObject->FsContext and on for example
IRP_MJ_READ I have to compare it ?

Thank you.

Igor Rosenberg
xxxxx@taureus.sk

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@itg.hitachi.co.jp
Sent: 17. októbra 2000 8:45
To: File Systems Developers
Subject: [ntfsd] Re: DASD I/O

Thank you for your replies.
As Tony wrote, we could get over the DASD I/O problem
by using the FileObject->FsContext value to compare two
file objects.

Thanks again for your time and assistance,

Regards,

Takashi


You are currently subscribed to ntfsd as: xxxxx@taureus.sk
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

tat’s rite. u may also consider tracking the file objects as well.

Ho Mun Chuen
xxxxx@pmail.ntu.edu.sg
@@ “Not everything that counts can be counted;
<” )~ and not everything that can be counted counts"
//\ … Albert Einstein
----- Original Message -----
From: “Igor Rosenberg”
To: “File Systems Developers”
Sent: Tuesday, October 17, 2000 9:53 PM
Subject: [ntfsd] Re: DASD I/O

Hello,

so on IRP_MJ_CREATE I have to store FileObject->FsContext and on for example
IRP_MJ_READ I have to compare it ?

Thank you.

Igor Rosenberg
xxxxx@taureus.sk

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@itg.hitachi.co.jp
Sent: 17. okt?bra 2000 8:45
To: File Systems Developers
Subject: [ntfsd] Re: DASD I/O

Thank you for your replies.
As Tony wrote, we could get over the DASD I/O problem
by using the FileObject->FsContext value to compare two
file objects.

Thanks again for your time and assistance,

Regards,

Takashi


You are currently subscribed to ntfsd as: xxxxx@taureus.sk
To unsubscribe send a blank email to $subst(‘Email.Unsub’)


You are currently subscribed to ntfsd as: xxxxx@pmail.ntu.edu.sg
To unsubscribe send a blank email to $subst(‘Email.Unsub’)