Dynamic VPB swap

NTFSD
1

I was wondering if it is possible to swap a VPB on the fly, to change
the underlying volume without affecting the file system handle owned by
an application. Some tests done so far seem to show that VPB is cached
somewhere and changes done to the structure does not reflect live.

Also, how does the IO Manager knows which volume to link to a file
system when it mounts it? Is that persistent information in the
registry?

Thanks

2

No, you cannot. When old FSD wil flush its caches, it will ruin the new
volume which is no more valid for these caches.

Remount is the only chance.

FSDs are enumerated in their registration order, and each is given a try to
mount. The one which will recognize the metadata is the one which will be
really mounted.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Veilleux, Eric” wrote in message news:xxxxx@ntfsd…
I was wondering if it is possible to swap a VPB on the fly, to change
the underlying volume without affecting the file system handle owned by
an application. Some tests done so far seem to show that VPB is cached
somewhere and changes done to the structure does not reflect live.

Also, how does the IO Manager knows which volume to link to a file
system when it mounts it? Is that persistent information in the
registry?

Thanks

3

In fact the architecture of the system is such that the “file system
handle” to VPB association is persistent, even if you change the VPB in
the media device object.

Look at the file object - it has a Vpb pointer in it. The I/O Manager
uses that pointer, not the one in the device object, if it is present.
That’s what ensures file objects are handed to the right file system
(think about removable media, where FO->Vpb refers to the file system
that controlled the media when the file was opened. If we handed that
FO to a different file system it probably wouldn’t be able to handle
it.) Thus, you can take a CD drive, mount a CDFS volume, swap to a FAT
volume, and then to a UDFS volume and everything “just works right”.

So, what you see is a feature and is expected behavior.

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Veilleux, Eric
Sent: Wednesday, May 02, 2007 6:37 AM
To: ntfsd redirect
Subject: [ntfsd] Dynamic VPB swap

I was wondering if it is possible to swap a VPB on the fly, to change
the underlying volume without affecting the file system handle owned by
an application. Some tests done so far seem to show that VPB is cached
somewhere and changes done to the structure does not reflect live.

Also, how does the IO Manager knows which volume to link to a file
system when it mounts it? Is that persistent information in the
registry?

Thanks

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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Actually, this isn’t true. There are two kinds of file systems
(“normal” and “low priority”) and mounting is done in reverse order of
registration (LIFO). Thus, RAW registers first but is called last.
Normal priority file systems are called before low priority file
systems.

The priority scheme was introduced to allow supporting DVDs (which
contain both a UDF and ISO 9660 file system layout) with UDF without
degrading functionality. As an oddity, I’ve been told that the reason
both file system formats are present is because Microsoft explicitly
requested they both be present as a compatibility/scheduling
consideration (in the Windows 98 timeframe as I recall.)

We’ve been “burned” by the ordering issue because the I/O Manager will
stop processing mount requests when anything other than a small set of
expected errors is returned during the mount process. We discovered
this with an FSD that supported WORM media - if NTFS was called first,
it would get an I/O error on an unwritten region of the media and the
mount would abort. If the WORM file system was called first, it just
worked right (and worst of all, it was a *specific piece of media* that
exhibited this behavior. Ah, what a fun bug that was to resolve.)

Tony

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