Symbolic link support

[jetwhiz]

Environment

• Windows version: Windows 7
• Processor architecture: x86
• Dokany version: v1.0.0-RC4
• Library type (Dokany/FUSE): FUSE

Check List

• I checked my issue doesn't exist yet
• [?] My issue is valid with mirror default sample and not specific to my user-mode driver implementation
• I can always reproduce the issue with the provided description below.
• I have updated Dokany to the latest version (https://github.com/dokan-dev/dokany/releases) and have reboot my computer after.

Description

Is symbolic link creation support implemented for Dokany FUSE?

I looked through the fusemain.cpp source code but didn't notice where ops_.symlink is being called, and when I run a mklink request on the command line for encfs4win, my symlink function is never triggered.

From what I can tell (here), mklink is triggering create_file, which doesn't appear to trigger ops_.symlink anywhere.

Logs

mklink Z:\b.txt Z:\x\a.txt

###Create 0002
CreateFile: \b.txt
        DesiredAccess: SYNCHRONIZE|DELETE|FILE_WRITE_ATTRIBUTES
        ShareAccess: 0x0
        Disposition: FILE_CREATE (2)
        Attributes: 128 (0x80)
        Options: 2097248 (0x200060)
CreateFile status = 0 - lastError = 0
###GetFileInfo 0002
GetFileInfo: : \b.txt
        result =  0
        FileStandardInformation
        DispatchQueryInformation result =  0
###Create 0003
CreateFile: \
        DesiredAccess: SYNCHRONIZE|FILE_READ_DATA
        ShareAccess: FILE_SHARE_DELETE|FILE_SHARE_WRITE|FILE_SHARE_READ
        Disposition: FILE_OPEN (1)
        Attributes: 144 (0x90)
        Options: 16417 (0x4021)
CreateFile status = 0 - lastError = 0
###FindFiles 0003
FindFiles: \
index from 0
FileMatch? : . (b.txt,0,0)
FileMatch? : .. (b.txt,0,0)
FileMatch? : b.txt (b.txt,0,0)
  =>return single entry
index to 1
###Cleanup 0003
Cleanup: \

###Close 0003
Close: \

###GetFileInfo 0002
GetFileInfo: : \b.txt
        result =  0
        FileBasicInformation
        DispatchQueryInformation result =  0
###GetFileInfo 0002
GetFileInfo: : \b.txt
        result =  0
        FileStandardInformation
        DispatchQueryInformation result =  0
###GetFileInfo 0002
GetFileInfo: : \b.txt
        result =  0
        FileInternalInformation
        DispatchQueryInformation result =  0
###SetFileInfo 0002  13
GetFileInfo: : \b.txt
DeleteFile: \b.txt
  dispositionInfo->DeleteFile = 1
        DispatchSetInformation result =  0
###Cleanup 0002
Cleanup: \b.txt

###Close 0002
Close: \b.txt

[kyanha]

symlinks in Windows are implemented by the filesystem code as reparse points, which require Fsctl implementation. Dokany doesn't yet support Fsctl dispatch, and as a result Dokany doesn't yet support reparse points.

Here's the documentation I've been able to find about this, on the Windows side.

####Fsctls required

• FSCTL_GET_REPARSE_POINT
• FSCTL_DELETE_REPARSE_POINT
• FSCTL_SET_REPARSE_POINT

####Structures

• _REPARSE_DATA_BUFFER
• _REPARSE_DATA_BUFFER_EX

####Microsoft Open Standards

• MS-FSCC
• Specific section of MS-FSCC for IO_REPARSE_TAG_SYMLINK

[pomaroff]

Are there any plans to support symlinks in Dokany? The driver-side handles the Fsctl events but none of them are forwarded to userland code.

If there are no plans, what would an ideal implementation look like?

• FSCTL_GET_REPARSE_POINT
• FSCTL_DELETE_REPARSE_POINT
• FSCTL_SET_REPARSE_POINT

I understand that these are the only 3 Fsctl events that we would need to forward to userland code to get this working, so would it be preferred to have 3 specific userland callback functions for them?

Otherwise, if there a need for Dokany to forward other Fsctl events (either now or in the future) would it instead be preferred to have something that generically allows for handling any Fsctl event in userland code?

[Liryna]

We are not currently planning to implement this feature in the near future but I am happy to review pull requests!

I understand that these are the only 3 Fsctl events that we would need to forward to userland code to get this working, so would it be preferred to have 3 specific userland callback functions for them?

I would think we could have only one userland event sent that has the FsControlCode as param. SET and DELETE would have the needed input data attached with it.
Maybe the userland library should split the request based on FsControlCode to call the right callback. This would avoid the implementation to know about FSCTL_*_REPARSE_POINT.

Otherwise, if there a need for Dokany to forward other Fsctl events (either now or in the future) would it instead be preferred to have something that generically allows for handling any Fsctl event in userland code?

This is also a way it could be implemented but maybe might be more complex to be implemented by userland FS ? At least reparse point is a more well-known fsctl compared to others that could be received.
See here the current proposal #544