dokan-dev / dokany

User mode file system library for windows with FUSE Wrapper
http://dokan-dev.github.io
5.23k stars 666 forks source link

Warnings from DDK regarding INF-file #648

Open Rondom opened 6 years ago

Rondom commented 6 years ago

https://ci.appveyor.com/project/Maxhy/dokany/branch/master/job/o9718w9o7ujdf4nr/messages

 (InfVerif target) -> 
   C:\projects\dokany\sys\dokan.inf(33-33): warning 1205: Section [DokanFileSystem.DriverFiles] referenced from DelFiles and CopyFiles directive. [C:\projects\dokany\sys\sys.vcxproj]
Liryna commented 6 years ago

Hi @Rondom ,

I saw it too, tried to see how bad it is and how it should be done but found nothing unfortunately. 😢

Liryna commented 6 years ago

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/inf-delfiles-directive

destination-file-name
Specifies the name of the file to be deleted from the destination.

Do not specify a file that is listed in a CopyFiles directive. If a file is listed in both a CopyFiles-referenced and a DelFiles-referenced section, and the file is currently present on the system with a valid signature, the operating system might optimize away the copy operation but perform the delete operation. This is very likely not what the INF writer intended.

But SwapBuffers sample is also doing the same: https://github.com/Microsoft/Windows-driver-samples/blob/master/filesys/miniFilter/swapBuffers/swapBuffers.inf

😢

Mattiwatti commented 6 years ago

Hiya,

I also ran into this and found that even the "nullFilter" MS sample driver (nullFilter.inf) (which does literally nothing) generates this warning! Very frustrating. Since this was the first result on Google after searching for this warning, I'll post my solution here (relevant sections only):

Before:

[DestinationDirs]
DefaultDestDir          = 12
NullFilter.DriverFiles  = 12            ;%windir%\system32\drivers

[DefaultInstall]
OptionDesc  = %ServiceDescription%
CopyFiles   = NullFilter.DriverFiles

[DefaultUninstall]
DelFiles   = NullFilter.DriverFiles

[NullFilter.DriverFiles]
%DriverName%.sys

As you can see both CopyFiles and DelFiles refer to [NullFilter.DriverFiles] which is what's causing the warning. And after reading the note in @Liryna's post I do believe it makes sense to generate a warning here, but only because the default behaviour is backwards and counterintuitive. When upgrading/replacing an existing driver with the same filename, I would expect the above INF file to (1) delete any existing .sys file, and (2) copy the new .sys file, not (1) silently perform a delete without copy (if your driver is a boot driver, you just killed your system)!

I split [NullFilter.DriverFiles] into [NullFilter.CopyDriverFiles] and [NullFilter.DeleteDriverFiles], both still containing the same filename. This is enough to get rid of the warning, but does not fix the underlying problem. To do this, I set flags 0x10001 = (DELFLG_IN_USE | DELFLG_IN_USE1) on the 'delete' section (ref: DelFiles directive) and flags 0x2000 = COPYFLG_NOPRUNE on the 'copy' section (ref: CopyFiles directive). The former ensures that any existing files are deleted. The latter is the important one: it prevents the CopyFiles operation from being "optimized away" (scary thought...)

So the final INF file looks like this:

[DestinationDirs]
DefaultDestDir                = 12
NullFilter.DeleteDriverFiles  = 12      ;%windir%\system32\drivers
NullFilter.CopyDriverFiles    = 12      ;%windir%\system32\drivers

[DefaultInstall]
OptionDesc  = %ServiceDescription%
CopyFiles   = NullFilter.CopyDriverFiles

[DefaultUninstall]
DelFiles   = NullFilter.DeleteDriverFiles

[NullFilter.DeleteDriverFiles]
%DriverName%.sys,,,0x00010001 ;(DELFLG_IN_USE | DELFLG_IN_USE1)

[NullFilter.CopyDriverFiles]
%DriverName%.sys,,,0x00002000 ;COPYFLG_NOPRUNE

I tested this and was able to replace a running and attached minifilter driver file without issues on Windows 7 and Windows 10 (the latter does not normally allow you to delete driver files while they are loaded, so that seems to indicate it's working).

Note that this only takes care of replacing the file(s), not stopping the service. The 0x200 = SPSVCINST_STOPSERVICE flag on DelService is supposed to take care of this and is already set in the sample INF, but this doesn't happen. After reading the MSDN documentation at DelService I believe the cause of this is not so much that the flag is broken, but rather that the DelService operation is not invoked since the driver is not really being 'uninstalled' in this case, only 'reinstalled' or 'upgraded'. Fortunately starting or stopping services is fairly easy to do yourself in an installer script/program.

Liryna commented 6 years ago

Hi @Mattiwatti ,

Thank you for your feedback and research ! 🏆

I have tested the solution you provided and it also removes the warning on our side https://github.com/dokan-dev/dokany/pull/682. But as I understand doing this breaks the the 0x200 = SPSVCINST_STOPSERVICE flag on DelService like you said because windows do not understand it is an uninstall anymore right ?

Liryna commented 2 years ago

Filesystem are special type of driver that cannot be of primitive type. Closing this for now as it does no looks to be possible to be fixed.

Liryna commented 1 year ago

This is now mandatory to sign the driver. I was able to make it work but Windows complains that the system needs to restart due to changes of existing files which is not the case (we only copy the driver in System32/drivers). Therefore we have two solutions to avoid this:

The first option is easy and future proof while the second allows us to support older versions for a time.