Does a "delete" make sense for a dosdevice?

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 :slight_smile:

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.

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.

Otherwise I’ll just do it all with IOCTL’s.

Thanks

James

File and namespace semantics outside of opening the handle are FS concepts. Use the.ioctl

d

Bent from my phone


From: James Harpermailto:xxxxx
Sent: ?12/?13/?2013 6:23 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] Does a “delete” make sense for a dosdevice?

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 :slight_smile:

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.

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.

Otherwise I’ll just do it all with IOCTL’s.

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</mailto:xxxxx></mailto:xxxxx>

IRP_MJ_SET_INFORMATION/FileDispositionInformation

> 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 :slight_smile:

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

>

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

Challenge. Accepted. :slight_smile:

I do understand that just because it ‘works’ doesn’t mean it’s a good idea, but it’s easy enough to test.

James

I don’t see any reason it wouldn’t work, as long as the command prompt shell parses and acts on just the device name the same way it does a file-spec.

Peter
OSR

>>

> 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

Challenge. Accepted. :slight_smile:

I do understand that just because it ‘works’ doesn’t mean it’s a good
idea, but it’s easy enough to test.

I suspect it won’t “work”. But, if it does, then you will get some kind
of weird IRP, and after reading the docs on said weird IRP you may have
enough to figure out what to do.
joe

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

It’s not any sort of “weird” IRP. The function is Set Information. It can also be done by simply setting a flag on open.

Delete on Windows has an interesting set of semantics:
http://www.osronline.com/article.cfm?article=245

Peter
OSR

>

I don’t see any reason it wouldn’t work, as long as the command prompt
shell parses and acts on just the device name the same way it does a file-
spec.

I’m not actually going to use the command prompt to do the delete, it would be done from the usermode service.

Using open and delete operations to control the creation of the child device simplifies the IOCTL requirements immensely as I don’t have to track a whole load of conditions. Instead of:

OPEN
IOCTL_CREATE_MY_DEVICE (can only be called once per connection)
IOCTL_CONNECT_MY_DEVICE:
(pended until ready to disconnect to ensure no pages left unmapped)
(CREATE must have already been called)
IOCTL_GET_MY_REQUEST
IOCTL_COMPLETE_MY_REQUEST
IOCTL_REMOVE_DEVICE
CLOSE

It can be:

OPEN
IOCTL_CONNECT_MY_DEVICE (no preconditions now)
IOCTL_GET_MY_REQUEST
IOCTL_COMPLETE_MY_REQUEST
CLOSE
OPEN for delete
CLOSE

Maybe I can even check how the file is being opened, eg open for create, open only if existing, etc.

I’m still worried that this might be too unixy for Windows :slight_smile:

James

By the standards of most devices, getting this would be weird. It would
be common for a filesystem driver, but not for, say, a PCI driver or a USB
driver sitting directly on top of USBD. That was all I meant by “weird”
joe

It’s not any sort of “weird” IRP. The function is Set Information. It
can also be done by simply setting a flag on open.

Delete on Windows has an interesting set of semantics:
http://www.osronline.com/article.cfm?article=245

Peter
OSR


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

> I don’t see any reason it wouldn’t work, as long as the command prompt shell parses and acts

on just the device name the same way it does a file- > spec.

Well, the most obvious reason why it may fail is because symbolic links are Object Manager’s concept under Windows and not the ones of the file system. Although Object Manager tries to implement some functionalities that is normally associated with VFS under other OSes (like, for example, handle management) it is still not the one. After all, it is a driver who creates a symbolic link \DosDevices\mydriver, effectively making newly-created \Device\mydriver accessible by Win32 API. It does so without any explicit request from the user apps, filesystem, etc. Therefore, would not it be reasonable to expect this driver to be the only one who is responsible for deleting this link upon device deletion, and doing so without any explicit requests from anyone?

This is very different from the other OSes where symbolic link is a 100% FS concept - it gets created upon the user request and gets deleted upon the one. Unlike hard links, symbolic ones don’t imply the target’s knowledge of themselves, so that a link and its target may reside on different volumes that are managed by different subsystems. However, under Windows a target driver is very well aware of the symbolic links, because it creates the ones. Therefore, what James suggests is a totally UNIX-like way of doing things that I suspect may(in fact, I would even say should) fail under Windows…

Anton Bassov

There should be no expectation that “delete” on a dosdevice will delete a symbolic link. The driver doesn’t even know which symbolic link was used to open the handle (to call DeleteFile).

My impression, however, is that the OP has a handle to a device with a
named set of bits on it, and wishes to delete one of those names and its
corresponding set of bits. This is a property of the device, and to the
best of my knowledge, at no point did the concept of “symbolic link” enter
the OP’s spec. So it is irrelevant to the discussion, except insofar as
“del \.\mydriver\whatever” is supposed to communicate with \.\mydriver,
pass it the string “whatever”, and expect the named set of bits to go
away. If, for some bizarre reason, the driver had created the symbolic
link “gratuitousalias”, then “delete \.\gratuitousalias\whatever” should
have the same effect. Peter seemed to suggest that in either case the
driver will receive an IRP specifying “whatever” be deleted. For that
matter, if the device were opened by a CreateFile on its interface name,
and the DELETE flag was specified, the implication was that when this
handle (for simplicity, we will ignore DuplicateHandle/inheritance or
opening multiple handles; these only add gratuitous exposition with
already-documented behavior) is closed, then the same IRP will be issued.
What the driver does with this is up to the driver. I would think at this
point some experimentation is in order.
joe

There should be no expectation that “delete” on a dosdevice will delete a
symbolic link. The driver doesn’t even know which symbolic link was used
to open the handle (to call DeleteFile).


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

>If I do “del \.\mydriver\somefile” from a command prompt, what IRPs does my driver get?

SetInformationFile/FileDispositionInformation


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

> This is very different from the other OSes where symbolic link is a 100% FS concept

Windows has both.

Linux also has both. Windows OM == Linux’s devfs.

Is “rm” supported on devfs?


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com