Single thread causes the saving of WORD doc file fail

[GoogleCodeExporter]

I have an issue on Vista similar to issue 42.

When I edit and save a new doc file in a dokan drive, it will hang if the 
thread 
number is "1". However, it will be normal if the thread number is "2".

os: Vista
app: Microsoft Office 2003
dokan version: snapshot from SVN (Doc 5 2009)
attachment: DebugView log of single thread case is attached.

Original issue reported on code.google.com by shyhchyu...@gmail.com on 6 Oct 2009 at 3:46

Attachments:

• singlethread.LOG

[GoogleCodeExporter]

Power point in Office 2003 also has the same issue.
Excel in Office 2003 has a little different issue. Saving an xls file 
successes, but 
reopening the xls file will hang if the thread number is 1.

Original comment by shyhchyu...@gmail.com on 6 Oct 2009 at 3:55

[GoogleCodeExporter]

I suspect this has to to do with flushing the cache: when trying to just close a
certain excel file, dokan.sys hangs in the DokanCompleteCleanup function.

The line it hangs on is this:

    CcFlushCache(&fcb->SectionObjectPointers, NULL, 0, NULL);

When I attach windbg to the client process, dokan.dll hangs in the
SendEventInformation function on 

    status = DeviceIoControl(...)

I suspect what happens is that the flush of the cache causes an IRP_MJ_WRITE (in
order to write the dirty cache pages), which can't be executed because the 
(single)
user space thread is still busy trying to signal completion of the cleanup.

I don't see how this would be fixable in a single-threaded scenario.

Original comment by t.s.mae...@gmail.com on 13 Nov 2009 at 1:10

[GoogleCodeExporter]

Actually, this could be REALLY bad: 
1) imagine you have user space dokan handler 5 threads.
2) Now you perform 5 cleanups in parallel... 
3) all 5 threads are busy trying to signal completion
4) the dokan driver tries to flush the cache for first one

-> there is not user-space thread available, so the cache flush takes forever

Original comment by t.s.mae...@gmail.com on 13 Nov 2009 at 1:23

[GoogleCodeExporter]

flushing the cache before dispatching the cleanup seems to fix the problem. 

Here's a patch:

### Eclipse Workspace Patch 1.0
#P sys
Index: cleanup.c
===================================================================
--- cleanup.c   (revision 39)
+++ cleanup.c   (working copy)
@@ -88,6 +88,10 @@
        fcb = ccb->Fcb;
        ASSERT(fcb != NULL);

+       CcFlushCache(&fcb->SectionObjectPointers, NULL, 0, NULL);
+       CcPurgeCacheSection(&fcb->SectionObjectPointers, NULL, 0, FALSE);
+       CcUninitializeCacheMap(fileObject, NULL, NULL);
+
        eventLength = sizeof(EVENT_CONTEXT) + fcb->FileName.Length;
        eventContext = AllocateEventContext(vcb->Dcb, Irp, eventLength, ccb);

@@ -167,9 +171,6 @@
        FsRtlNotifyCleanup(vcb->NotifySync, &vcb->DirNotifyList, ccb);
    }

-   CcFlushCache(&fcb->SectionObjectPointers, NULL, 0, NULL);
-   CcPurgeCacheSection(&fcb->SectionObjectPointers, NULL, 0, FALSE);
-   CcUninitializeCacheMap(fileObject, NULL, NULL);
    fileObject->Flags |= FO_CLEANUP_COMPLETE;

Original comment by t.s.mae...@gmail.com on 13 Nov 2009 at 2:03

[GoogleCodeExporter]

I fixed the issue. Thank you very match for your investigation and patch.

Original comment by asa...@gmail.com on 25 Dec 2009 at 6:58

• Changed state: Fixed