Hello Experts,
I have created a USB Mass Storage device with a PDIUSBD12 target
controller. I have successfully written the target side driver and am
able to do all kinds of disk operation on it.
I now have a requirement of selectively preventing disk operations as
below:
a) Prevent users from creating any directories on the disk
b) Prevent users from formatting the disk
c) Prevent users from storing any file on the disk whose name is NOT
"MyFile.bin"

I have been able to do all the above successfully in Windows XP because
when ever the user performs a disk operation, XP first writes data to
the "root directory" sectors and then to the rest of them. So, whenever
I get a request for any disk operation that needs to write to the "root
directory" sectors, I first do a validation on the root directory
related data and if it does not meet the above constraints, I stall the
operation and return a "Write Protect" status in the the following
request sense command. All this works perfectly well in XP.
However in Windows 2000, the sequence of disk operation is different.
The root directory is NOT written to first. Due to this reason, I am
not able to do such a validation on the same.
This difference in behaviour in Win 2K is because the mass storage
driver is configured for "Better performance" than "Quick Removal". In
Win 2K there is no option to change this seeting (unlike Win XP). Is
there a registry tweak to change this setting? Thanks.

<ganeshokade@gmail.com> wrote in message news:1126077863.075323.63100@g43g2000cwa.googlegro ups.com...
So, you mean that XP writes the directory entry first, then goes the data?
Then if the disk is surprisely removed in between, the data is corrupted.
A very strange optimization for quick removal...

--PA

"Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
news:uK5j0%235sFHA.284@TK2MSFTNGP14.phx.gbl...
Actually that is not so strange. NTFS is structured to reduce damage to its
own structures but not to reduce damage to file contents. If you have a
file open for writing when Windows XP blue-screens, your file will contain
some sectors full of binary zeroes instead of the data that you thought you
wrote. Why should surprise removals cause less damage to user files than
BSODs do.

In order to reduce damage to user data, someone would have to copy some
techniques that Honeywell used more than 30 years ago. When the system came
back up after crashing, user files contained their old data, as if they had
not even been opened for writing before the crash. But Microsoft didn't
exist at that time, so I don't think they're going to copy it.

You need a filesystem filter in your device driver package (several months
of development usually). And note - the smart user can wipe if off from the
system and will be able to bypass these preventions.

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

<ganeshokade@gmail.com> wrote in message
news:1126077863.075323.63100@g43g2000cwa.googlegro ups.com...