Question on parsing a file path containing mount points

NTFSD
1

I’m reading Rajeev Nager’s book on NT file system design, and of course,
reading the discussions on this list, and I’m having a bit of trouble
understanding just how Mr. Nager’s file system would go about handling
NT mount points now when parsing the path. The discussions on this list
indicate that the FSD would return a STATUS_REPARSE to the I\O manager
to cause it to reparse the path, but it seems as if there’s some
difference in what its going to reparse…
Some people seem to indicate that the file system should change
FileObject->FileName.
Others seem to think that a REPARSE_DATA_BUFFER should be created in
Irp->Tail.Overlay.AuxiliaryBuffer with the new path to the file.
Some indicate that setting iosb->Status = IO_REPARSE works. Others note
this only works when a related file object is present.
Some discussions indicated that a fully normalized path name was needed,
others point to the offset field of the reparse data buffer.

My question is then this. When implementing a simple file system such
as Mr. Nager’s, how does one handle multiple mount points in a file
path? Is there a set of rules that one can follow? Do I need to create
a reparse_data_buffer or can I just change the open path to reflect the
normalized name of the new mount point for the rest of the path and
return STATUS_REPARSE?

Thanks,
Allan

2

Mr. Graves,

Your description confuses multiple items together with respect to mount
points and reparse points.

First, a “reparse point” is a generic mechanism for redirecting an
IRP_MJ_CREATE operation to a different file or directory than the
initial caller expected. A specific instance of a reparse point
includes - but is not limited to - mount points.

Mount points are actually implemented inside the I/O Manager, which
makes it a bit unusual as a reparse point. However, from the NTFS
perspective (or any other file system that supports reparse points) this
is a simple operation: the reparse point data is returned in
Irp->Tail.Overlay.AuxiliaryBuffer by NTFS. The interpretation of that
data contents is the responsibility of higher layers (filters and/or the
I/O Manager).

When a higher layer wishes to change the parsing of the name, it does so
by changing the FileObject->FileName component; this could then either
redirect the I/O operation at that point (to another file system, for
example) or it could return it to the OS (STATUS_REPARSE, IO_REPARSE) so
that the Object Manager ultimately restarts the parse.

With that said, your question doesn’t make much sense to me at least -
if the file system is “simple” then why is it supporting reparse points?
If you DO support reparse points, how do you distinguish “multiple” from
“one”, since you could use the NTFS restriction that a file (or
directory) have at most one reparse point.

If you are trying to implement reparse points and wish to only support
those reparse options managed directly by the OS, it is sufficient to
rewrite the name in the file object. If you wish to implement a
general-purpose reparse point mechanism, you’ll need to return them in
the reparse data buffer (when applicable) and in the file object when
you don’t expect any further interpretation by any intervening filter.

So, perhaps the bottom line explanation is:

  • The component that expects to return the new path name to the Object
    Manager does so by setting it in the FileObject->FileName component.
  • The component that expects a higher level OS component (including I/O
    manager or filter driver) to resolve the new path should return that
    information in the auxiliary data buffer.

I hope this helps.

Regards,

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Allan Graves
Sent: Tuesday, September 06, 2005 7:33 PM
To: ntfsd redirect
Subject: [ntfsd] Question on parsing a file path containing mount points

I’m reading Rajeev Nager’s book on NT file system design, and of course,

reading the discussions on this list, and I’m having a bit of trouble
understanding just how Mr. Nager’s file system would go about handling
NT mount points now when parsing the path. The discussions on this list

indicate that the FSD would return a STATUS_REPARSE to the I\O manager
to cause it to reparse the path, but it seems as if there’s some
difference in what its going to reparse…
Some people seem to indicate that the file system should change
FileObject->FileName.
Others seem to think that a REPARSE_DATA_BUFFER should be created in
Irp->Tail.Overlay.AuxiliaryBuffer with the new path to the file.
Some indicate that setting iosb->Status = IO_REPARSE works. Others note

this only works when a related file object is present.
Some discussions indicated that a fully normalized path name was needed,

others point to the offset field of the reparse data buffer.

My question is then this. When implementing a simple file system such
as Mr. Nager’s, how does one handle multiple mount points in a file
path? Is there a set of rules that one can follow? Do I need to create

a reparse_data_buffer or can I just change the open path to reflect the
normalized name of the new mount point for the rest of the path and
return STATUS_REPARSE?

Thanks,
Allan

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com