Dokan library скачать для windows 10 x64

The code to delete a directory in mirror.c is the following:

hFind = FindFirstFile(filePath, &findData);
while (hFind != INVALID_HANDLE_VALUE) {
    if (wcscmp(findData.cFileName, L"..") != 0 &&
        wcscmp(findData.cFileName, L".") != 0) {
        FindClose(hFind);
        DbgPrint(L"  Directory is not empty: %sn", findData.cFileName);
        return -(int)ERROR_DIR_NOT_EMPTY;
    }
    if (!FindNextFile(hFind, &findData)) {
        break;
    }
}
FindClose(hFind);

if (GetLastError() == ERROR_NO_MORE_FILES) {
    return 0;
} else {
    return -1;
}

The deletion is actually done in dokan code, the value returned here just indicate if it is OK to delete the file or not. returning 0 triggers the file deletion.

When the directory is not empty, hFind is valid, we enter the loop and exit at some point with ERROR_NO_MORE_FILES as last error, all is fine.

When the directory is empty, hFind is INVALID_HANDLE_VALUE and so is the last error, therefore we return -1 and the directory is not deleted.

Here’s an interesting one for you. It’s really quite difficult to uninstall Dokany from the command line. I have a Windows Server Core install that I’m using to test the BSOD bug and now I can’t remove Dokan.

Does the RC4 installer support any command line switches?

I installed dokan 0.7.0 and try:
mirror.exe /r e:/test /l M*
create empty folder and then delete it, blue screen occure.

I try dokan 0.6.0, it work fine.

Hi,
Is it possible to use Dokan as a raw disk, and create a filesystem on it?

Thanks!

Just when I thought it was safe to develop on my laptop again.
I think this was caused when I was sitting at a breakpoint in Visual Studio.

3: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: ffffffffffffffe8, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff800cc121c8f, If non-zero, the instruction address which referenced the bad memory
    address.
Arg4: 0000000000000000, (reserved)

Debugging Details:
------------------


Could not read faulting driver name

READ_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
 ffffffffffffffe8 

FAULTING_IP: 
nt!ObQueryNameStringMode+5f
fffff800`cc121c8f 410fb64618      movzx   eax,byte ptr [r14+18h]

MM_INTERNAL_CODE:  0

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  AV

PROCESS_NAME:  CCleaner64.exe

CURRENT_IRQL:  2

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

TRAP_FRAME:  ffffd0002663ed50 -- (.trap 0xffffd0002663ed50)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00ffffffffffffff rbx=0000000000000000 rcx=0000000000000000
rdx=00000000000000ff rsi=0000000000000000 rdi=0000000000000000
rip=fffff800cc121c8f rsp=ffffd0002663eee0 rbp=0000000000000000
 r8=00000000000000fe  r9=ffffd0002663f078 r10=fffff801ea485b80
r11=ffffd0002663f148 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         ov up ei pl nz na po cy
nt!ObQueryNameStringMode+0x5f:
fffff800`cc121c8f 410fb64618      movzx   eax,byte ptr [r14+18h] ds:00000000`00000018=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff800cbe2904a to fffff800cbdd8d00

STACK_TEXT:  
ffffd000`2663eb08 fffff800`cbe2904a : 00000000`00000050 ffffffff`ffffffe8 00000000`00000000 ffffd000`2663ed50 : nt!KeBugCheckEx
ffffd000`2663eb10 fffff800`cbcaa536 : 00000000`00000000 00000000`00000000 ffffd000`2663ed50 ffffe000`c0e40180 : nt! ?? ::FNODOBFM::`string'+0x4174a
ffffd000`2663ec00 fffff800`cbde1dbd : 00000000`00008000 fffff800`cbefd68d ffffe000`c2dfd000 ffffd000`2663eda0 : nt!MmAccessFault+0x696
ffffd000`2663ed50 fffff800`cc121c8f : 00000000`00000800 00000000`00000801 20206f49`00000008 fffff800`cbcd93e6 : nt!KiPageFault+0x13d
ffffd000`2663eee0 fffff800`cc1b5126 : 00000000`00000000 ffffe000`bb5f9f00 ffffe000`000000fe ffffd000`2663f078 : nt!ObQueryNameStringMode+0x5f
ffffd000`2663f000 fffff801`ea49954c : ffffd000`2663f0f0 00000000`00000000 00000000`c000014f fffff800`cbd31a4d : nt!ObQueryNameString+0xe
ffffd000`2663f040 fffff801`ea498322 : 00000000`00000000 ffffd000`2663f0b0 00000000`00000000 00000000`00000000 : FLTMGR!FltpGetObjectName+0x30
ffffd000`2663f070 fffff801`ea492d8c : ffffe000`be1f2980 ffffe000`c2204080 00000000`00000000 00000000`00000000 : FLTMGR!FltpFsControlMountVolume+0xa2
ffffd000`2663f150 fffff800`cc16eae2 : fffff800`cbfca540 00000000`00000000 ffffe000`c0e40080 ffffe000`c0e40080 : FLTMGR!FltpFsControl+0x14c
ffffd000`2663f1b0 fffff800`cbd53364 : ffffe000`c2204080 ffffe000`bfc6a990 ffffe000`c2204080 ffffd000`2663f480 : nt!IopMountVolume+0x35a
ffffd000`2663f430 fffff800`cc0b7367 : 00000000`00000005 00000000`00000000 ffffd000`2663f790 00000000`00000000 : nt!IopCheckVpbMounted+0x154
ffffd000`2663f480 fffff800`cc0b29d1 : ffffc000`b5e2a718 ffffc000`b5e2a718 ffffd000`2663f790 ffffe000`c2204050 : nt!IopParseDevice+0x4a7
ffffd000`2663f690 fffff800`cc11138c : ffffe000`bb3c7001 ffffd000`2663f8b8 00000000`00000040 ffffe000`ba20bf20 : nt!ObpLookupObjectName+0x711
ffffd000`2663f830 fffff800`cc10d69c : 00000000`00000001 ffffe000`bfc6a990 00000000`009ef2e0 00000000`009ef2d0 : nt!ObOpenObjectByName+0x1ec
ffffd000`2663f960 fffff800`cc10d25c : 00000000`009ef2b8 00000000`00000000 00000000`009ef2e0 00000000`009ef2d0 : nt!IopCreateFile+0x38c
ffffd000`2663fa00 fffff800`cbde3363 : 00000000`00000102 00000000`00000001 00000000`00000001 00000000`00000000 : nt!NtOpenFile+0x58
ffffd000`2663fa90 00007fff`be6e382a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`009ef268 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007fff`be6e382a


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!ObQueryNameStringMode+5f
fffff800`cc121c8f 410fb64618      movzx   eax,byte ptr [r14+18h]

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  nt!ObQueryNameStringMode+5f

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  55c9bcb6

IMAGE_VERSION:  10.0.10240.16431

BUCKET_ID_FUNC_OFFSET:  5f

FAILURE_BUCKET_ID:  AV_nt!ObQueryNameStringMode

BUCKET_ID:  AV_nt!ObQueryNameStringMode

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:av_nt!obquerynamestringmode

FAILURE_ID_HASH:  {9eb41a12-81ba-71f6-0c3d-31180b493b51}

Followup: MachineOwner
---------

I have not been able to find a way to call DokanUnmount() such that it actually succeeds. Not only that but dokanctl.exe /u M also fails. The only way I can unmount the drive is by executing dokanctl.exe /u M /f however DokanMain() still doesn’t return and additional calls to DokanUnmount() also fail.

I am running a console application and DokanMain() is being called on its own thread with DOKAN_OPTION_KEEP_ALIVE | DOKAN_OPTION_DEBUG.

Is there a C example somewhere because i would like to port dokan in another high-level language but i can’t find example :/

thanks

This is on Dokan 0.7.4.
I’d be happy to provide further details — if I had access to the 0.7.4 pdb.

Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:WindowsMEMORY.DMP]
Kernel Bitmap Dump File: Full address space is available

************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV_C:Windowssymbol_cache_http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV_C:Windowssymbol_cache_http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17936.amd64fre.winblue_ltsb.150715-0840
Machine Name:
Kernel base = 0xfffff802a3a06000 PsLoadedModuleList = 0xfffff802a3cdb7b0
Debug session time: Fri Sep 4 19:35:30.194 2015 (UTC + 2:00)
System Uptime: 0 days 0:12:38.930
Loading Kernel Symbols
………………………………………………………
……………………………………………………….
……………………………………………………….
…………..
Loading User Symbols

Loading unloaded module list
……….

• ---

Use !analyze -v to get detailed debugging information.

BugCheck 7E, {ffffffffc0000005, fffff802a3a94cb9, ffffd000219c86b8, ffffd000219c7ec0}

*** ERROR: Module load completed but symbols could not be loaded for dokan.sys
Probably caused by : dokan.sys ( dokan+2523 )

Followup: MachineOwner

4: kd> !analyze -v

• ---

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff802a3a94cb9, The address that the exception occurred at
Arg3: ffffd000219c86b8, Exception Record Address
Arg4: ffffd000219c7ec0, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 — The instruction at 0x%08l referenced memory at 0x%08lx. The memory could not be «%s».

FAULTING_IP:
nt!IopfCompleteRequest+a69
fffff802`a3a94cb9 488b4018 mov rax,qword ptr [rax+18h]

EXCEPTION_RECORD: ffffd000219c86b8 — (.exr 0xffffd000219c86b8)
ExceptionAddress: fffff802a3a94cb9 (nt!IopfCompleteRequest+0x0000000000000a69)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000019
Attempt to read from address 0000000000000019

CONTEXT: ffffd000219c7ec0 — (.cxr 0xffffd000219c7ec0;r)
rax=0000000000000001 rbx=ffffe00158824350 rcx=0000000000000884
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000001
rip=fffff802a3a94cb9 rsp=ffffd000219c88f0 rbp=ffffd000219c89f0
r8=0000000000000001 r9=ffffe00158888800 r10=fffff801e9674280
r11=ffffd000219c8a28 r12=00000000a000000c r13=0000000000000000
r14=ffffe00158836f00 r15=00000000a0000003
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010202
nt!IopfCompleteRequest+0xa69:
fffff802a3a94cb9 488b4018 mov rax,qword ptr [rax+18h] ds:002b:0000000000000019=????????????????
Last set context:
rax=0000000000000001 rbx=ffffe00158824350 rcx=0000000000000884
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000001
rip=fffff802a3a94cb9 rsp=ffffd000219c88f0 rbp=ffffd000219c89f0
r8=0000000000000001 r9=ffffe00158888800 r10=fffff801e9674280
r11=ffffd000219c8a28 r12=00000000a000000c r13=0000000000000000
r14=ffffe00158836f00 r15=00000000a0000003
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010202
nt!IopfCompleteRequest+0xa69:
fffff802a3a94cb9 488b4018 mov rax,qword ptr [rax+18h] ds:002b:0000000000000019=????????????????
Resetting default scope

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 — The instruction at 0x%08l referenced memory at 0x%08lx. The memory could not be «%s».

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000019

READ_ADDRESS: unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
0000000000000019

FOLLOWUP_IP:
dokan+2523
fffff801`e966e523 4883c428 add rsp,28h

BUGCHECK_STR: AV

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff801e966e523 to fffff802a3a94cb9

STACK_TEXT:
ffffd000219c88f0 fffff801e966e523 : ffffe00158824350 fffff802a3e60900 ffffe001627b53d0 ffffe00158836ef0 : nt!IopfCompleteRequest+0xa69
ffffd000219c8a30 fffff801e9671244 : ffffe00157496540 ffffe00158837da0 ffffe00158836f68 ffffe00158836e30 : dokan+0x2523
ffffd000219c8a60 fffff801e9670b7e : ffffe00158836f68 ffffe00158837da0 ffffe00158836e30 ffffe00158836f68 : dokan+0x5244
ffffd000219c8aa0 fffff801e9671d6c : ffffe0015fd9c0b0 ffffe00158837da0 ffffe00158836e30 ffffe00100000002 : dokan+0x4b7e
ffffd000219c8af0 fffff801e96719d1 : fffffffffffe7960 0000000000000001 0000000000000080 ffffe00158837da8 : dokan+0x5d6c
ffffd000219c8b30 fffff801e9671c4e : ffffe00158837da0 0000000000000000 ffffe00157309801 0000000000000000 : dokan+0x59d1
ffffd000219c8b60 fffff802a3b040a8 : 0000000000000000 ffffe00158834080 ffffe00158834080 0000000000000000 : dokan+0x5c4e
ffffd000219c8c00 fffff802a3b5bfc6 : ffffd0012f0a7180 ffffe00158834080 ffffd0012f0b33c0 fffff802a3a9fd28 : nt!PspSystemThreadStartup+0x58
ffffd000219c8c60 0000000000000000 : ffffd000219c9000 ffffd000219c3000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: dokan+2523

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dokan

IMAGE_NAME: dokan.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 55d73d9a

STACK_COMMAND: .cxr 0xffffd000219c7ec0 ; kb

FAILURE_BUCKET_ID: AV_dokan+2523

BUCKET_ID: AV_dokan+2523

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:av_dokan+2523

FAILURE_ID_HASH: {9d91f95c-aa94-4f23-2d77-0f802f2a29b4}

Followup: MachineOwner

Hello,

I hope this finds you well, in good spirit and having a good day.

I would like to start helping with the Dokany project, if I can.

However because my experience is mostly from Linux/GNU programming, I would need help to get started with the Visual Studio, please.

I created a Windows Server 2008 R2 virtual machine, and installed Visual Studio 2013 Express for Desktop with the WDK 8.1 as written on:

https://github.com/dokan-dev/dokany/wiki/Build

But I do not understand or find how to do this:

«On VS menu, select Generate => Background Configuration then check all Win32/x64 Release configuration and click on Generate.»

My friend who has worked with Visual Studio before could not tell me what does it mean either.

I did give him remote desktop access to the box, and he tried to build it, but it said 4 succeed 2 failed, and that it built dokan.dll but could not find dokan.lib.

It would be great if you can help me get started with this, as I hope I can then be able to get into it and help to fix things in the future.

Has anyone been able to build it according to the Build page instructions out of the box?

Sorry for the ‘newbie’-ish issue, but once I get over it, hopefully I can get cracking!

Further advice and clarification would be great.

With best wishes,

Kalle.

Hello everybody!
There are several bugs with memory-mapped files:

1. Wrong behaviour in MirrorWriteFile:
   If a «Write» request comes from Virtual Memory Manager ( DOKAN_PAGING_IO is set ) then a file size will must not to be changed.
   For example:
   h = CreateFile(…)
   MapWrite( h, data = «Hello World» )
   CloseFile(h)
   After that the file size is equal to 4K( page size ) although the file size should be equal to 11 bytes
   Try to use this code:

   static int DOKAN_CALLBACK MirrorWriteFile( ... )
   {
       ...

       FileSize = GetFileSize(...);
       LARGE_INTEGER distanceToMove;

       if ( DokanFileInfo->WriteToEndOfFile )
       {
           if( DokanFileInfo->PagingIo )
            {
                *NumberOfBytesWritten = 0;
                return 0;
            }
            LARGE_INTEGER z;
            z.QuadPart = 0;
            if ( !SetFilePointerEx( handle, z, NULL, FILE_END ) )
            {
                 DbgPrint(L"tseek error, offset = EOF, error = %dn", GetLastError());
                 return -1;
            }
        }
        else
        {
            if( DokanFileInfo->PagingIo  )
            {
                if( Offset >= FileSize )
                {
                    return 0;
                }

                if( ( Offset + NumberOfBytesToWrite ) > fi.FileSize )
                {
                    NumberOfBytesToWrite = fi.FileSize - Offset;
                }
            }

            if( Offset > fi.FileSize )
            {
                //In the mirror sample helperZeroFileData is not necessary. NTFS will zero a hole.
                //But if user's file system is different from NTFS( or other Windows's file systems ) then  users will have to zero the hole themselves.
                err = helperZeroFileData( ... );
                if( err )
                {
                    return -1;
                }
            }

            distanceToMove.QuadPart = Offset;
            if ( !SetFilePointerEx( handle, distanceToMove, NULL, FILE_BEGIN ) )
            {
               DbgPrint(L"tseek error, offset = %d, error = %dn", offset, GetLastError());
                return -1;
            }
        }

        ...
    }

1. Wrong behaviour in driver’s DokanDispatchWrite, DokanDispatchRead, DokanDispatchSetInformation( set EOF ):
   Previous mapped files are not flushed in DokanDispatchWrite, DokanDispatchRead. Also they are not invalidated in DokanDispatchWrite, DokanDispatchSetInformation.
   For example:
   h = CreateFile(…)
   MapWrite( h, offset = 0x100, length = 0x10, data = 0xaa )
   WriteFile( h, offset = 0x100, length = 0x10, data = 0x00 )
   MapRead( h, offset = 0x100, length = 0x10, buffer )
   After MapRead buffer will not contain zero data

   Try to use:

NTSTATUS DokanDispatchRead( ... )
{
    ...
    if (fcb->Flags & DOKAN_FILE_DIRECTORY)
    {
        DDbgPrint("   DOKAN_FILE_DIRECTORY %pn", fcb);
        status = STATUS_INVALID_PARAMETER;
        __leave;
    }

    if (Irp->Flags & IRP_PAGING_IO) 
    {
        isPagingIo = TRUE;
    }

    if(
          !isPagingIo &&
          ( fileObject->SectionObjectPointer != NULL ) &&
          ( fileObject->SectionObjectPointer->DataSectionObject != NULL )
      )
    {
       ExAcquireResourceExclusiveLite( &fcb->PagingIoResource, TRUE );
       CcFlushCache(
                    &fcb->SectionObjectPointers,
                    &irpSp->Parameters.Read.ByteOffset,
                    irpSp->Parameters.Read.Length,
                    NULL
                   );
         ExReleaseResourceLite( &fcb->PagingIoResource );
    }
    ...
}

NTSTATUS DokanDispatchWrite( ... )
{
    ...
    if (Irp->Flags & IRP_PAGING_IO) 
    {
        isPagingIo = TRUE;
    }

    if(
          !isPagingIo &&
          ( fileObject->SectionObjectPointer != NULL ) &&
          ( fileObject->SectionObjectPointer->DataSectionObject != NULL )
      )
    {
       ExAcquireResourceExclusiveLite( &fcb->PagingIoResource, TRUE );
       CcFlushCache(
                    &fcb->SectionObjectPointers,
                    writeToEoF ? NULL : &irpSp->Parameters.Write.ByteOffset,
                    irpSp->Parameters.Write.Length,
                    NULL
                   );
        CcPurgeCacheSection(
                   &fcb->SectionObjectPointers,
                   writeToEoF ? NULL : &irpSp->Parameters.Write.ByteOffset,
                   irpSp->Parameters.Write.Length,
                   FALSE
                  );
         ExReleaseResourceLite( &fcb->PagingIoResource );
    }
    ...
}

NTSTATUS DokanDispatchSetInformation( ... )
{
    ...
    switch (irpSp->Parameters.SetFile.FileInformationClass)
    {
        ...
    case FileEndOfFileInformation:
        if( 
            ( fileObject->SectionObjectPointer != NULL ) &&
            ( fileObject->SectionObjectPointer->DataSectionObject != NULL )
          )
        {
            ExAcquireResourceExclusiveLite(&fcb->Resource, TRUE);

            pInfoEoF = (PFILE_END_OF_FILE_INFORMATION)buffer;
            //Not truncate an image file if it has been already mapped
            if (!MmCanFileBeTruncated( fileObject->SectionObjectPointer, &pInfoEoF->EndOfFile ) )
            {
                status = STATUS_USER_MAPPED_FILE;
                __leave;
            }

            ExReleaseResourceLite(&fcb->Resource);

            //Real file size is in an user mode app. So flush and invalidate a whole region
            if( !isPagingIo )
            {
                ExAcquireResourceExclusiveLite( &fcb->PagingIoResource, TRUE );
                CcFlushCache(&fcb->SectionObjectPointers, NULL, 0, NULL);
                CcPurgeCacheSection(&fcb->SectionObjectPointers, NULL, 0, FALSE);
                ExReleaseResourceLite( &fcb->PagingIoResource );
             }
        }
        ...
    }
    ...
}

For fixing some issue and becoming more stable, Dokan need

• KeepAlive no longer a option.
• Use NTSTATUS for interface functions — For now: LONG = NTSTATUS * -1 — Will break compatiblity
• Use LookasideList
• Merge DriverEntry (catch all exception in one place like cdfs) #55
• SectionObjectPointers have the information about Memory Manager and if the file is memory mapped. But we need to implement it in a clean way. see #32
• Add Oplock Semantics
• Change EnumerateNamedStreams to work like FindFiles
• Change Dokan Mount Service by Microsoft Mount Manager (requires Plug & Play) see #50
• Read-only device option #72
• CreateFile SL_CASE_SENSITIVE, SL_FORCE_ACCESS_CHECK, SL_OPEN_PAGING_FILE are not currently handled at all. #99
• Add option for normal user to mount device as Global
• Disable network device when mount point folder is specified

Hello,
Did anybody else encounter a problem with setting access rules with inheritance on a folder?
I tried to set the following SDDL — O:BAG:BAD:PAI(A;OICI;FA;;;WD)
which means —

Owner: Administrators
Group: Administrators
Rights: Everyone - Full Control
        For all subfolders

When I check the security settings on the folder, I see that they apply only for the current folder.

I tried to check if it works in the Mirror project, but the security tab doesn’t show up in the mirrored drive. Probably because it works with the future version of Dokan, and not 0.7.4.

Thanks!

I should mention that me being active in this project is not entirely without self interest. I started a prototype project for a radically new, versatile filesystem called Cameleonica. If it gains traction then dokan will be of interest to me.

I would like to establish some official cooperation between our endeavors. I submitted a heavy set of changes to your wiki, code comments, and io site. I am happy to see that you accepted them.

https://github.com/arekbulski/Cameleonica/blob/master/README.md

I am looking forward to having people review my ideas, especially from people that are not technical in this topic. Having external perspective is always helpful. If you would spend some time to read it, please post an Issue with your questions and remarks. I am looking forward to answering them.

originally, dokan.sys [6.0.0] source code had a race condition issues as follows :

NTSTATUS
DokanFreeFCB(
  __in PDokanFCB Fcb
  )
{
        // sth is omitted ...

    Fcb->FileCount--;  // here!!

    if (Fcb->FileCount == 0) {  // and here!!

        RemoveEntryList(&Fcb->NextFCB);

current dokan.sys is fixed as follows :

NTSTATUS
DokanFreeFCB(
  __in PDokanFCB Fcb
  )
{
    PDokanVCB vcb;

        // sth is omitted...

    InterlockedDecrement(&Fcb->FileCount);  // fixed code...

    if (Fcb->FileCount == 0) {

        RemoveEntryList(&Fcb->NextFCB);

I think current code is much better… but not perfect.
there is still race condition issue between InterlockedDecrement and if statement.
If multiple threads execute «InterlockedDecrement(&Fcb->FileCount);» statement at the same time, above code is risk that no thread enter «if (Fcb->FileCount == 0)» block.

It should be fixed as follows :

NTSTATUS
DokanFreeFCB(
  __in PDokanFCB Fcb
  )
{
    LONG        FileCount = 0;
    // sth is omitted...

    FileCount = InterlockedDecrement(&Fcb->FileCount);      // should be fixed like this!!

    if (FileCount == 0) {

        RemoveEntryList(&Fcb->NextFCB);

According to the above code, even if multiple thread enter DokanFreeFCB at the same time, only (and at least) one thread will enter «if (FileCount == 0)» block.

I am trying to make my own fs using mirror.c sample as a basis, but it seems to me that there will be race conditions if multiple threads will be accessing it concurrently.
For example in the MirrorCleanup there is such code:

        CloseHandle((HANDLE)DokanFileInfo->Context);
        DokanFileInfo->Context = 0;

        if (DokanFileInfo->DeleteOnClose) {
            DbgPrint(L"tDeleteOnClosen");
            if (DokanFileInfo->IsDirectory) {
                DbgPrint(L"  DeleteDirectory ");
                if (!RemoveDirectory(filePath)) {
                    DbgPrint(L"error code = %dnn", GetLastError());
                } else {
                    DbgPrint(L"successnn");
                }
            } else {
                DbgPrint(L"  DeleteFile ");
                if (DeleteFile(filePath) == 0) {
                    DbgPrint(L" error code = %dnn", GetLastError());
                } else {
                    DbgPrint(L"successnn");
                }
            }
        }

But wouldn’t it be possible that after CloseHandle another thread will delete this file, and create new file in it’s place?
Similar problem seems to be in MirrorDeleteDirectory function, that function is checking that the directory being deleted is empty, but what if new file will be created after this check but before directory really will be deleted?

Also in multiple functions there is code similar to this:

    if (!handle || handle == INVALID_HANDLE_VALUE) {
        DbgPrint(L"tinvalid handle, cleanuped?n");
        handle = CreateFile(
            filePath,
            GENERIC_READ,
            FILE_SHARE_READ,
            NULL,
            OPEN_EXISTING,
            0,
            NULL);
        if (handle == INVALID_HANDLE_VALUE) {
            DbgPrint(L"tCreateFile error : %dnn", GetLastError());
            return -1;
        }
        opened = TRUE;
    }

But in what cases can you get invalid handle sent to your function? And is it really okay to just reopen file here?

Maybe I am missing something?

Mount Manager is no longer an option on current Windows OS.
This issue to discuss/tracks changes on mountmanager branch to support it correctly on Dokan.

• PnP support: this would be great of course but doesn’t seem mandatory. Non-pnp device can notify mount manager with IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION (see DokanSendVolumeArrivalNotification). Also, PnP should be an option on DokanOptions for users who doesn’t want their File System to be PnP.
• Volume Links: the way Volume Links (??Volume{x} and DosDeviceM) are created is wrong. Mount Manager take care about the first one following IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION and the second one should be created with IOCTL_MOUNTMGR_CREATE_POINT. Ideally the driver shouldn’t have to be aware of volume link names.
• IoRegisterFileSystem: For details, see previous discussion on #48.
• Recycle Bin: mounting correctly the volume will require to support high level feature like Recycle Bin (currently end up to a corrupted recycled bin each time the volume is mounted).
• Remove dokan mount service

Hi.

This is 50% question 50% feature request. I promise that if I get the first 50% I’ll send a pull request updating the docs.

I failed to install the driver by following the instructions coming from the original dokan repository. I compiled the project just fine by opening the solution in Visual Studio, but running «dokanctl.exe /i d» got me just an error. I ran with DebugView, and the error was:

[1912] Service (Dokan) installed
[1912] failed to start service (Dokan): 1275
[1912] Service (Dokan) start failed

Seems this error code is ERROR_DRIVER_BLOCKED («This driver has been blocked from loading.»). This isn’t very helpful, and what I’ve found searching wasn’t helpful either.

I ran the installer that you provide (thank you!) and it works. From the log it prints, I see it does more or less the same, so I don’t know what could be different.

In a previous setup I got it to work, but it was the original dokan on Vista with WDK 7. Now it’s Windows 8 with WDK 8 and dokany.

If you have any hints I would be very grateful, since I am going to use extensively some Dokan implementation, and being able to run something I’ve built myself could be quite important.

Thank you.

I have modified the .net RegistoryFS sample the GetFileInformation method to return an information if the key ends with temp

          if (filename.EndsWith("TEMP"))
            {
                fileinfo.Attributes = System.IO.FileAttributes.ReadOnly;
                fileinfo.LastAccessTime = DateTime.Now;
                fileinfo.LastWriteTime = DateTime.Now;
                fileinfo.CreationTime = DateTime.Now;
                return 0;
            }

Then I have executed the test and navigated to CurrentUserEnvironment and made a double click on the TEMP entry. Windows 7 x64 brings up a message «The directory name is invalid»

Have you an idea why?

The whole example is build to return GetFileInformation only if it is a directory, otherwise it returns -1

I recently published an interface to mount the ipfs distributed file system as a Windows drive via dokan:

https://github.com/alexpmorris/dipfs

Using the version of dokan 0.6.0 included in my repo, it works perfectly on 32-bit Windows, as well as 64-bit Windows 7.

I wanted to see if your updated dokany version would work as well, and while it worked as expected throughout operation, when I hit ctrl-C to kill the program (which should also dismount the drive), the PC immediately blue-screened each time.

At first I thought it was something I did wrong, but then I tried your version of mirror.exe, and the same bluescreen occurred when I tried to close down mirror.exe as well. This happened with both dokany version 0.7.2 and 0.7.3-rc2.

If it would help, I can send a minidump. But basically, it shows:

dokan.sys+2a00 PAGE_FAULT_IN_NONPAGED_AREA

For example, try dokanct.exe /v to get the version number

There’s a milliseconds flash of a window on my screen but nothing else.

If I’m reading the source correctly, with ARGV<3 it should display usage… which also flashes up too fast to read.

Same issue with the other .exe files as well?

I’m currently trying to build a java wrapper for dokan with BridJ, but the second callback always fails with ERROR_INVALID_HANDLE. This is the debug output:

[4472] Dokan: debug mode on
[4472] device opened
[4472] mounted: D: -> DokanRedirector{d6cc17c5-1710-4085-bce7-964f1e9f5de9}
[4472] ###Create 0000
[4472]    CreateDisposition 108X
[4472] CreateFile status = 0
[4472] Ioctl failed with code 6

Increasing the number of threads to 3 yields the following:

[5348] Dokan: debug mode on
[5348] device opened
[5348] mounted: D: -> DokanRedirector{d6cc17c5-1709-4085-bce7-964f1e9f5de9}
[5348] ###Create 0000
[5348]    CreateDisposition 108X
[5348] CreateFile status = -2
[5348] Ioctl failed with code 6
[5348] ###Create 0001
[5348]    CreateDisposition 108X
[5348] CreateFile status = -2
[5348] Ioctl failed with code 6
[5348] ###Create 0002
[5348]    CreateDisposition 108X
[5348] CreateFile status = -2
[5348] Ioctl failed with code 6

What could be the cause of this problem? Locked resources? I would appreciate any hints. I’m a Java developer and really not into drivers / windows / C.

I extracted some code to illustrate the issue: https://github.com/sherter/dokan4j
Use gradlew run to run the main function in Test.java. If you have eclipse installed, you can use gradlew eclipse to generate eclipse project metadata. Afterwords you can import it in eclipse as existing project. Let me know if you have any problems running the code.

Hi.

According to a message from Maxime, and the Unsupported wiki page, Vista is supported, but the installer refuses to continue in it. I still have an ancient machine that I would like to use to test my app. If you could change the installer to allow installations on Vista, I would again be very thankful.

Hello,

I use Dokan 0.7.3 RC (latest) for FISSH on Windows 8.1 Pro x64.

I have BSOD everytime I shutdown the computer.
If I uninstall Dokan, the BSOD dissapears.

Is there à fix for this?

Thanks.

I have a 64-bit Windows 8.1 system. After mounting a drive (say I mount it to F:), I cannot unmount it with DokanCtl.exe /u F or DokanCtl.exe /u F:. It will say that the mounter is Dokan’s mounter.exe, path is Dokan’s SYS file and Unmount status: 0.

I use Dokany with this application: https://cuemounter.codeplex.com/, so I’m not sure it is a Dokan issue.

Please look into it.

Hi, dokan/dokany is used in encfs4win but there is a problem: the mounted drive is not seen by indexing service of windows so its content is not fast-searchable.
I don’t know if it is a limit of how encfs4win uses dokany or it is not yet a supported feature of dokany, in the latter case this issue is to possibly ask for it.
cheers

Giuse

When calling SetAccessControl() on a DirectoryInfo instance in C# the call sequence executed on a mounted IDokanOperationsProxy contains several calls with a redundant trailing backslash character:

OpenDirectory («Dir***«, …)
GetFileInformation («Dir***«,…)
Cleanup («Dir***«, …)
CloseFile («Dir***«, …)

This is the only known case where dokany calls the IDokanOperationsProxy with a trailing backslash in the filename (actually a directory name). Even in the same call sequence all other methods use the directory name without the trailing slash.
Please change the call pattern so that all file/directory paths are consistently named without a trailing backslash — with the exception of the root directory path .

See below for the full call sequence taken from a trace of the test DirectoryInfoTest.SetAccessControl_CallsApiCorrectly() in the DokanNet.Tests project.
Relevant filenames are emphasized in bold.

CreateFile[1] («», ..)
GetFileInformation[1] («», …)
Cleanup[1] («», …)
CloseFile[0] («», …)
CreateFile[1] («Dir», …)
GetFileInformation[1] («Dir», …)
CreateFile[2] («», …)
GetFileInformation[2] («», …)
GetFileSecurity[2] («», …)
Cleanup[2] («», …)
CloseFile[1] («», …)
GetFileInformation[1] («Dir», …)
GetFileSecurity[1] («Dir», …)
OpenDirectory[2] («Dir», …)
GetFileInformation[2] («Dir», …)
Cleanup[2] («Dir», …)
CloseFile[1] («Dir», …)
OpenDirectory[2] («Dir», …)
GetFileInformation[2] («Dir», …)
Cleanup[2] («Dir», …)
CloseFile[1] («Dir», …)
SetFileSecurity[1] («Dir», ..)
OpenDirectory[2] («Dir», ..)
GetFileInformation[2] («Dir», ..)
Cleanup[2] («Dir», …)
CloseFile[1] («Dir», …)
OpenDirectory[2] («Dir», …)
GetFileInformation[2] («Dir», …)
Cleanup[2] («Dir», …)
CloseFile[1] («Dir», …)
Cleanup[1] («Dir», …)
Waiting for closure (#1)
CloseFile[0] («Dir», …)

Can’t get encfs4win ( http://members.ferrara.linux.it/freddy77/encfs.html ) to work with dokany latest RC, with administrator user it works almost fine but with an usual user it outputs (encfs.cpp:141) error caught in getattr error for every directory listing or file access attempt (and it won’t open any files — gives «file not found» error). (folders open fine)

same error is given even when run as administrator when encrypted file is attempted to be deleted — so delete doesn’t work but modify does

Is this fixable from dokany?

*running in reverse mode: "C:Program Files (x86)Dokanencfs4winencfs.exe" --reverse -f C:test X: (same with local folders as mount-point)
Windows10 10240

I found 2 issues on the API wiki page that is unclear to me. If you would please explain, I will edit the wiki accordingly.

• FindFiles is supposed to return all directory entries for further filtering by dokan library? And is filtering entries prohibited in there?
• Mountpoint option «MountPoint» is supposed to demand that if C:… path is provided then C: must necessarily be using NTFS? Back in the old days, C drive could have been using FAT32.

Futher questions regarding comments in the code:

• https://github.com/arekbulski/dokany/blob/master/dokan/dokan.h#L322

  What the hell is CreateDirectly…

Hello,
I was wondering if it’s possible to implement missing features, such as InstallIcon() and SetIcon() for changing the disk’s icon.

Dokan vs. CBFS

Thanks!

The OS doesn’t create those files on a Dokan drive.
Is it because of how the dokan drive is built? Is it the same reason the dokan drive doesn’t have a recycle bin?

Thanks!

Hi!

I tried changing:

#define DOKAN_ALLOCATION_UNIT_SIZE  512

in public.h to 4096, and after I compiled and installed the dokan driver, the allocation size is still 512.

I tested it by creating a new txt file with just a couple of letters in it.
The size on disk appeared to be 512 bytes.

Thanks!

I use dynamic load in my app and notice that dokany does not export functions as original dokan did.
Only when modifying my loader function I can load it

static bool load_dokan ()
{
    HMODULE hmod = LoadLibrary("dokan");

#if DOKAN_VERSION == 600 // original dokan
    dllDokanMain = (tDokanMain) GetProcAddress (hmod, "DokanMain");
    dllDokanVersion = (tDokanVersion) GetProcAddress (hmod, "DokanVersion");
    dllDokanDriverVersion = (tDokanDriverVersion) GetProcAddress (hmod, "DokanDriverVersion");
#else // dokany
    dllDokanMain = (tDokanMain) GetProcAddress (hmod, "[email protected]");
    dllDokanVersion = (tDokanVersion) GetProcAddress (hmod, "[email protected]");
    dllDokanDriverVersion = (tDokanDriverVersion) GetProcAddress (hmod, "[email protected]");
#endif

Hi.

In some circumstances, we can’t get our application to work. DokanMain fails like this:

[3032] Dokan: debug mode on
[3032] Dokan Error: CreatFile Failed \.Dokan: 2
[3032] DokanMain completed with status -3
[3032] Can't install driver

The last two lines are the return value we get from DokanMain and the text in the dokan.h file next to the #define.

From what I see in the DokanMain code, that’s CreateFile returning ERROR_FILE_NOT_FOUND on the main driver device. What could cause this? Is there something that we can try to find out the issue? The installer worked fine, and gave no errors. What could be the reason theh device it’s not there?

Thank you.

PS: We are using DokanY 7.3 RC.

Hello Maxhy,

Sorry my lack of knowledge, I am starting at driver development. Would you mind to give me a brief explanation about, How you can sign a driver to work properly at Windows 64 bits enviroment ? Is there any company that does it for free ?

Thanks in advance.

i tested .net sample and delphi sample. in both apps, i can’t mount to an empty ntfs-path like d:test

DokanMain retrn with DOKAN_MOUNT_POINT_ERROR

I’ve been watching the progress of FUSE over Windows for years, and was sad when it seemed like Dokan had died on the vine. Thanks to everyone who has participated in it’s renovation, and especially for this fork.

Once in a while I have questions about the software but would rather not clutter this Git Issue Tracker with them. Is there a forum somewhere or other location where people are discussing it? Thanks!

I made a fork of mafintosh/fuse-bindings to add support for Windows using the FUSE API of this repo. It’s available at raymond-h/fuse-bindings.

It works, however at the moment, you need to both install Dokany for binary files, and clone the repo for the dokan-fuse headers.

It’d be great if the dokan-fuse headers were bundled with the install as well.

I’ve been puzzled by some hours after realizing that Windows Explorer on Windows 8 was removing files without actually ever calling the DeleteFile operation, nor receiving a Cleanup or Close operation with DeleteOnClose set.

I’ve found the explanations of the issue here:

• https://groups.google.com/d/topic/dokan/s5RPnXREWD8/discussion
• https://code.google.com/p/dokan/issues/detail?id=269

So it seems that since Windows 8 there is another way to delete files, and is opening them with FILE_FLAG_DELETE_ON_CLOSE in the dwFlagsAndAttributes parameter of CreateFile. Dokan doesn’t support that out of the box, but there are easy to work around.

1. Keep in the application the state of that flag from CreateFile to Cleanup, and remember to delete the file even if DeleteOnClose is not set in the DokanFileInfo structure. This is difficult on the file system application, and requires checking two flags for the same purpose, one coming from Dokan, other from the application itself.
2. Check the flag on CreateFile in the application and set DeleteOnClose to TRUE appropiately. This is easy, but it didn’t work for me. Probably Dokan overwrites it, as the application is only supposed to write in the Context variable.
3. Return an error in CreateFile if the flag is set. Windows Explorer will try to delete the file using DeleteFile as a fallback. This worked for me, but I don’t know if it’s the proper behaviour, and it could fail with other applications.

The other possibility is actually fixing it in Dokan, either by ensuring that workardound 2 can be done, or by setting DeleteOnClose like in the other cases.

If you think it should be done in the application, let me know, and I’ll update the documentation and close the issue.

Thank you!