Update without having to reboot ?

[benrubson]

trafficstars

Hi,

When we first install Dokan, no reboot is needed, and we can use it on the fly. Perfect. However, when a new version is available and we want to update it, we first need to remove current version and to reboot. Could it be possible for the new version to simply replace the existing version, without having to remove and reboot ? That's for example quite a difficult operation on a server.

Many thanks 👍

Ben

[Liryna]

Hi @benrubson ,

I understand the situation and specially for a server. This would be possible by making the driver Plug and Play https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/implementing-plug-and-play this requires some work and as far as I know only benefit in this situation to uninstall without reboot.

[Rondom]

Is it possible to have plug-and-play filesystem drivers? At least other drivers such as ext2fsd or btrfs-win require a reboot as well. Maybe they did not bother either, but maybe it has a reason?

[zanderz]

@Liryna Is there somewhere the scope of PnP implementation for Dokany has been discussed? How much work is it likely to be?

[Liryna]

Hi @zanderz ,

We have not looked more about this feature for now. I cannot say if this can be long or not to implement.

[overheadhunter]

Could it be possible for the new version to simply replace the existing version, without having to remove and reboot ? That's for example quite a difficult operation on a server.

While this would be the ideal solution, a feasible fallback could be to defer the driver replacement to the next regular reboot (as I proposed in #816).

[kyanha]

Apparent steps that would need to be dealt with:

1. dokan1.sys needs to respond to PNP IRPs

• https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/pnp-driver-design-guidelines
• https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj-pnp has pertinent information as well
• Need to forcibly close all currently-open file handles (if they aren't closed, the PnP manager won't finish the unload)
• Need to call unmount on all currently-mounted filesystems, because all filesystems that rely on the driver need to be disconnected from the system before the driver can be stopped
• This is the basic "driver can update without rebooting" level, but is disruptive to all running Dokany filesystem applications

2. dokan1.dll needs to receive a special "underlying dokany layer being upgraded" message from the driver

• Needs to basically sleep the entire current processing state of the filesystem, which shouldn't be too difficult -- as long as Unmount() doesn't call into the application code, all threads would be quiesced
• Needs to track the original arguments to DokanMount, so it can re-call DokanMount with original arguments after new version is installed, transparent to the filesystem application
• dokan1.sys will need to stop calling unmount on all currently-mounted filesystems (as implemented from step 1), or dokan1.dll needs to be able to intercept these calls when it's notified that the Dokany driver is updating, to enable this transparent remounting
• This is an enhanced "driver can update without rebooting and without disruption" level, which allows filesystem applications to continue running without forcing them to have application code to reconnect to the Dokany driver.

Implementation details of step 1 include:

• kernel programming, which requires specific skillsets.
• I don't know if a file system driver can even be able to be implemented in a way that the system knows it can be safely stopped and updated. Other types of device drivers certainly can be, but the documentation suggests that file system drivers are handled specially. Experimentation will be needed.
• The implementation of the DriverPnP routine to handle IRP_MJ_PNP seems straightforward, but I can't trust my evaluation in kernel space. (See the second link I put under step 1, regarding how IRP_MJ_PNP needs to be handled by file system minifilters.)

Implementation details of step 2:

• dokan1.dll needs to be prepared to wait on a semaphore that gets signaled by the newly-installed version of dokan1.sys.
• All files on the filesystem will still have to be forcibly closed (as far as the kernel can see), because the kernel won't finish the removal of anything from an open file's dependency stack. But if the DLL keeps the implementation threads of the application alive even as it's notified that the driver is being upgraded (and the DLL also saves the arguments to DokanMount), then it can quietly re-mount without necessarily having to break the state of the existing filesystem beyond all handles being closed.
• A multi-driver object stack might be possible to enable reopening the filehandles that were closed, as per the documentation for IRP_MJ_PNP and how file system minifilter drivers can react to IRP_MN_CANCEL_REMOVE_REQUEST.
• As a side note, when filesystem applications unexpectedly terminate, dokan1.sys should probably send an IRP_MN_SURPRISE_REMOVAL request to the PnP manager to ensure that all open files to that volume are closed. (See documentation for IRP_MJ_PNP.) This may be redundant, though, I'm not sure.

[Liryna]

Thank you @kyanha for your input. Indeed with such changes we could be able to unload the driver. In reality, file system drivers are hard or impossible to fully unload. Third part usually keeps reference on the driver and therefore force the I/O Manager to keep the driver alive even if unloaded. Only a reboot will fully release the driver.

I do not say we should not try and it is impossible, I just say that it is not up to use that the driver object will reach 0 reference and we will be unloaded,

[benrubson]

Then closing this for now, there's also #816, linking to related issues as well.

[ylgybbz]

it seems that winfsp project support unload driver. Is it because dokan cannot be unload dynamically due to differences in software implementation or architecture? @Liryna

[Liryna]

It is probably because it supports silo driver which would be a good idea to have. It allows to release the global resources dynamically without having the system keeping references on them even after unload.

Reopening this for visibility if anyone is interested in adding the support.!