DesiredAccess and ShareAccess fields in DOKAN_FILE_INFO

[Bill Zissimopoulos]

As DOKAN_OPERATIONS is currently designed there are 3 calls that a file system may get related to creating a new file handle:

• CreateFile
• CreateDirectory
• OpenDirectory

While CreateFile accepts DesiredAccess and ShareAccess parameters, there are no such parameters passed to CreateDirectory and OpenDirectory. Consequently there is no way for a file system to access those parameters.

Furthermore there is often the need to access those parameters at a time after the CreateFile call. For example, a file system that wants to properly implement FILE_SHARE_* must keep track of the readers/writers/deleters on a file and update the counts on CreateFile and Cleanup/CloseFile. Of course a file system could keep track of those flags itself (in DOKAN_FILE_INFO::Context), but it would be considerably simpler if Dokany made these flags conveniently available to the file system methods at all times.

I can provide patch if required.

Bill

[Liryna]

I do not see really the goal to have DesiredAccess and ShareAccess parameters for CreateDirectory and OpenDirectory.
None of this parameters are used to create or open a directory, why do you need it ?

About FILE_SHARE_* informations for readers/writers/deleters, I do not agree with you.
This part should be handle by the dokany driver himself.
If the dokany driver correctlly handle the sharing violation in the createfile (before calling the user createfile), no read/writer/delete will be called since the createfile has return a sharing violation error.
There is already a piece of implementation in the develop branch by marinkobabic but it does not handle a lots of case.
https://github.com/dokan-dev/dokany/commit/ac016e96d3381f207969ff0893accefd5a547b01
See the bottom of the discution: https://github.com/dokan-dev/dokany/issues/32

[Bill Zissimopoulos]

Liryna wrote:

I do not see really the goal to have DesiredAccess and ShareAccess parameters for CreateDirectory and OpenDirectory.
None of this parameters are used to create or open a directory, why do you need it ?

Hmmm... I am able to open a directory using:

CreateFile(name, GENERIC_READ, 0, 0, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0)

A second call to CreateFile with the same parameters results in ERROR_SHARING_VIOLATION. Therefore the ShareAccess parameter is important for directories too.

Now Dokany does not seem to call OpenDirectory() in this case because the Win32 CreateFile does not specify FILE_DIRECTORY_FILE when opening directories. But Microsoft has now documented NtCreateFile, etc. and many applications use them. So I can see a case where we get a FILE_DIRECTORY_FILE flag with restrictive ShareAccess, which is then routed to OpenDirectory().

The real fix here may be to simply remove OpenDirectory(). I believe it confuses matters and makes life harder for file system implementors. I mean we have to handle opening directories in CreateFile anyway! So now we have to handle opening directories in two methods (CreateFile, OpenDirectory) and in OpenDirectory() we do not even get all the information to do access checks, etc.

This ties into the discussion of adding the CreateOptions parameter to CreateFile. If the CreateOptions parameter was there, there would be little need for OpenDirectory (or CreateDirectory).

About FILE_SHARE_* informations for readers/writers/deleters, I do not agree with you.
This part should be handle by the dokany driver himself.
If the dokany driver correctlly handle the sharing violation in the createfile (before calling the user createfile), no read/writer/delete will be called since the createfile has return a sharing violation error.
There is already a piece of implementation in the develop branch by marinkobabic but it does not handle a lots of case.
https://github.com/dokan-dev/dokany/commit/ac016e96d3381f207969ff0893accefd5a547b01
See the bottom of the discution: https://github.com/dokan-dev/dokany/issues/32

I absolutely agree that this should be handled by Dokany. It just is not currently and I was looking for ways to implement it myself. If this implementation by marinkobabic (or similar) makes it into Dokany there is little reason to have the DesiredAccess and ShareAccess fields. So you can disregard my request.

Bill

[Liryna]

Ok, I see !
I agree, it is better to remove OpenDirectory than to change it.

Like in the other discussion, the split in calls for files and directory has no meaning.
It will need to be change in the future.