Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Does a "delete" make sense for a dosdevice?

James_HarperJames_Harper Member Posts: 1,615
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.

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

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,428
    File and namespace semantics outside of opening the handle are FS concepts. Use the.ioctl

    d

    Bent from my phone
    ________________________________
    From: James Harper
    Sent: ?12/?13/?2013 6:23 PM
    To: Windows System Software Devs Interest List
    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 :)

    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
    d
  • Alex_GrigAlex_Grig Member Posts: 3,238
    IRP_MJ_SET_INFORMATION/FileDispositionInformation
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > 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
    >
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > 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. :)

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

    James
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,138
    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    >>
    >> 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. :)
    >
    > 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
    >
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,138
    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • James_HarperJames_Harper Member Posts: 1,615
    >
    > 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 :)

    James
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
    >
  • anton_bassovanton_bassov Member Posts: 4,928
    > 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
  • Alex_GrigAlex_Grig Member Posts: 3,238
    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).
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
    >
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    >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
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    > 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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space