Closed GoogleCodeExporter closed 9 years ago
Please find a trace of filemon while I was trying to save a file on the volume.
Original comment by dek...@gmail.com
on 10 Feb 2009 at 1:23
Attachments:
The issue is still present in the current svn trunk. The trace is also similar
to what i have put in the png up there.
Original comment by dek...@gmail.com
on 11 Feb 2009 at 9:38
From the filespy trace it seems it s linked to the lack of FASTIO_* support.
From what I read there :
http://msdn.microsoft.com/en-us/library/ms790753.aspx
It seems to confirm that it s important as well. This could probably fix some
other issues.
Original comment by dek...@gmail.com
on 12 Feb 2009 at 5:36
Thank you very match for your information. I tried implementing fast io
dispatch
routines, but they seems not to be related the issue.
I also found a bug in write dispatch routine when Fileman is monitoring IO.
I updated the svn repository. Similar problems are happened when saving file on
offiece2007. I'm still investing the issue.
Original comment by asa...@gmail.com
on 12 Feb 2009 at 4:06
Hi,
I think I pinpoined where the error coming from. Using straceNT on Indesign i
collected a trace application
wise :
[T2464] CreateFileW(3f0b4e0, c0000000, 0, 0, ...) = 49c
[T2464] GetFileSize(49c, 12ed04, 4cd03b8, 3f0b440, ...) = 0
[T2464] SetFilePointer(49c, 6000, 12ecf8, 0, ...) = 6000
[T2464] SetEndOfFile(49c, 1, 3, 4f482e74, ...) = 1
[T2464] SetFilePointer(49c, 16000, 12eca4, 0, ...) = 16000
[T2464] SetEndOfFile(49c, 6, 10, 4f481c2e, ...) = 1
[T2464] SetFilePointer(49c, 0, 12ed08, 0, ...) = 0
[T2464] WriteFile(49c, 3ed0890, 1000, 12ed20, ...) = 1
[T2464] FlushFileBuffers(49c, 3f0b580, 3f0b440, 4f4891ad, ...) = 1
[T2464] WriteFile(49c, 3ed0890, 1000, 12ed18, ...) = 0
[T2464] GetLastError(3f0b580, 12ed44, 4f4879e2, 1, ...) = 57
Exception = e06d7363, Address = 7c81eb33 (first-chance!)
[T2464] GetLastError(0, 12ed38, 4edc8e18, 4f49db98, ...) = 57
[T2464] GetLastError(0, 12ed38, 4edc8eb6, 4edc8e98, ...) = 57
I have reproduced the error in a C program (Compile it with cl writetest.c -
sorry change the filename i was
lazy to get it through argv[1]).
If you remove the FlushFileBuffer the 2nd write works. If you keep it the 2nd
one get a 0x57 which is ERROR_INVALID_PARAMETER.
Original comment by dek...@gmail.com
on 13 Feb 2009 at 8:40
Attachments:
From what i read in fatsys source :
//
// CcFlushCache is always synchronous, so if we can't wait enqueue
// the irp to the Fsp.
//
if ( !FlagOn(IrpContext->Flags, IRP_CONTEXT_FLAG_WAIT) ) {
Would it be possible that the way dokan handle a flush by sending a
STATUS_PENDING being the cause of the
error for the next write ? (pure speculation from me).
Original comment by dek...@gmail.com
on 13 Feb 2009 at 8:49
Hello,
I could finally fix the issue. Your test program was really useful.
The problem was in flush dispatch routine. I updated the repository.
Thank you very match.
Original comment by asa...@gmail.com
on 13 Feb 2009 at 3:05
Original issue reported on code.google.com by
dek...@gmail.com
on 10 Feb 2009 at 1:20