> I set a symbolic link like WdfDeviceCreateSymbolicLink with a name
\DosDevices\mydriver, and that works fine.
If I do “del \.\mydriver\somefile” from a command prompt, what IRPs does
my driver get? Or doesn’t that question make sense on any level because my
driver is not a filesystem? (maybe I’m thinking too Linux 
I’ve browsed the docs for IRP_MJ_DELETE etc but nothing like that exists
so I’m wondering if a delete operation is only a filesystem concept.
Think about it. What does “delete” mean? It means “remove the directory
record that describes the association of this name with some bits, and
make the space occupied by those bits available for reuse”. Only file
systems have the ability to associate names with bits; in fact, that is
the definition of a file system!
Therefore, only the file system can figure out how to remove a name, and
below that level, all that you see is some sectors being written. Nobody
below the level of “file system” knows whether these sectors represent
data bits that are somehow associated with a name, or the bits which
define the on-device mapping tables from text names to bits (“directory
blocks”) or the data associated with the mechanisms to manage
free-vs-allocated blocks on the device (e.g. the FAT table for a FAT file
system).
Since your driver is not a file system, I suspect the I/O Mangler will
simply reject the request as nonsensical and you will get nothing.
joe
I want to have the usermode component of my driver open a certain path, eg
“\.\mydriver\pool\node”, and the resulting entity will be persistent (eg
to allow for a usermode crash and a reconnection without having to tear
everything down internally), but if usermode actually wants to tear down
the resulting entity, a delete operation makes some conceptual sense to
me.
Then you have created a file system. You have a mapping from names to
bits of some sort, you have persistence, and you have deletion. I don’t
think you can build this without calling it a file system.
You could, of course, simply create a set of IOCTLs to manage this; so you
could do a CreateFile on
“\.\mydriver”
which gives you a handle on the entire device, and then you could issue
IOCTLs to do things like deletion on the device. If you care about
security (anyone who has access to the device could delete a named object
in the device, even if it was in use) you probably need a full-out file
system model, so you can control who has access to what.
Otherwise I’ll just do it all with IOCTL’s.
See above comment. You have all kinds of nasty problems if you do this,
and you will end up creating a p-baked file system for p very much less
than 0.5 (which would be half-baked).
joe
Thanks
James
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer