General help + Questions

Hi, Masters!

(you can send partial answers, because it’s quite long)

…I’ve been working on special cache FS driver for some
four months, and by now I’ve implemented most of it; the
problem is, that is *FULL* of bugs, and even if it does
most of the job, it’s very unstable…

…so I decieded to rewrite it, from the scratch; I would
like to write it more clearly and in a less chaotical way;
for this I would like to group the MUST-TO-IMPLEMENT like
IRP codes and features for Win2K; the idea is to make a
minimal FS driver base (a template) wich does NOT provide
any working READ or WRITE features, etc., but only some
clearly defined base routines (like Dispatch, etc.);

after that I could extend it with the problem-specific
parts; I created a list with those items, that MUST be
implemented (in a template-like way) to have a working
base, and it would be usefull for me (and not only) to have
a clear confirmation on this list from somebody, who knows
it more precisely (I’m not a 100% dedicated driver writer);
particularry, it would be excellent to have a coherent
list about the MUST-TO like subfunction, FSCTL codes, etc.

minimal, absolutely required list to have the basic
functionallity for Explorer, etc. (list, properties, etc.)
(if it is possible, consider NOT a theoretical, but an
“in-practice” MUST-TO-IMPLEMENT point of view)

  • DriverEntry()
  • FileDirectoryInformation
  • FileFullDirectoryInformation
  • FileBothDirectoryInformation
  • FileNamesInformation
    (Question: all of them are necesarry, for Explorer, etc.?)
    (Q: any other FSCTL/IRP_MN_xxx is MUST-TO-IMPLEMENT like?)
  • FileBasicInformation
  • FileStandardInformation
  • FileNameInformation
  • FilePositionInformation
    (Q: any other is MUST-TO-IMPLEMENT like?)
  • FileFsAttributeInformation
  • FileFsDeviceInformation
  • FileFsFullSizeInformation
  • FileFsSizeInformation
  • FileFsVolumeInformation
    (Q: any other is MUST-TO-IMPLEMENT like?)
  • a dispatch routine for asynchronous IRP processing using
    the system’s worker threads
  • a driver object
  • a main device object (for the FSD itself)
  • one volume object per mounted volume
  • one driver specific structure (file control block) per every
    logical file that is in use
  • one driver specific structure per every file handle
    (wich is identified by FileObject->FsContext)

extended items, that should also be present, either to
enhache the FS’s capability or to support general READ
and WRITE operations

  • FileBasicInformation
  • FileDispositionInformation
  • FilePositionInformation
  • FileRenameInformation
  • FileAllocationInformation
  • FileEndOfFileInformation
    (Q: anything more?)
  • FileFsVolumeInformation
  • FileFsLabelInformation
  • FileFsSizeInformation
  • FileFsAttributeInformation
  • FileFsFullSizeInformation
    (Q: anything more is necesarry?)
  • IRP Cancellation mechanism

Q: it is required (in MUST-TO sense) to handle PNP IRPs?

read and write related items, to provide minimal, but
correctly working read and/or write functionallity

    Q: if I don’t use the NT Cache Manager, nor the VMM,
    then I need to provide support for IRP_MN_MDL and

I have also a few other questions:

Q1: even if I can handle very well file open requests
issued by CreateFile() like sources (ex. Windows Commander),
but, in the majority of cases, I can’t handle requests from
standard Windows open dialog boxes (I click on the file, and
nothing happens); the FSD is getting the open request, but
after that I got a huge number of FileStandardInformation or
DIRECTORY requests (even thousands) (I don’t handle directory
change notification, but simply send back STATUS_INVALID_
DEVICE_REQUEST); has anybody an idea what is going on?,
or which requests are specific to the Windows Explorer and
Windows open dialog boxes, that can cause such thing?

Q2: if I don’t use any physical media (like hdd, partition,
etc.; I make some virtual cache items in the memory) then
I don’t need to implement MOUNT/UNMOUNT and other volume
related functions? (I mean that if I don’t implement them,
the Win32 subsystem, etc. would work just fine)

Q3: in this particular situation, I dont need to implement
PNP IRPs? (it works without, but I’m not sure that is safe)

Q4: generally, when I got a NON-supported FSCTL or
IRP_MJ_QUERY_INFORMATION subfunction code, etc. what is
the correct (or advised) answer (and behaviour of my FSD):
STATUS_INVALID_DEVICE_REQUEST ? (maybe an other response?)


Do you want a free e-mail for life ? Get it at

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)