SetAllocationInformation error: can't handle this parameter.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run 3dsMax 2009 and try to save to a 3ds max file.
2. 3dxmax hangs as Dokan driver is hung after it fails to execute
SetAllocationInformation
3. The allocInfo->AllocationSize.QuadPart is set to non-zero (512) and
causes the DokanSetAllocationInformation to issue the warning and hang.

What is the expected output? What do you see instead?
The 3ds max file should be written normally.

What version of the product are you using? On what operating system?
0.42 on XP SP3

Please provide any additional information below.
Here is the Dokan debug log around the error :

###Create 0054
   CreateDisposition 2
CreateFile : c:/tmp/dokan\coo.max
    CREATE_NEW
    ShareMode = 0x1
    FILE_SHARE_READ
    AccessMode = 0x12019f
    FILE_READ_DATA
    FILE_READ_ATTRIBUTES
    FILE_READ_EA
    READ_CONTROL
    FILE_WRITE_DATA
    FILE_WRITE_ATTRIBUTES
    FILE_WRITE_EA
    FILE_APPEND_DATA
    SYNCHRONIZE
    STANDARD_RIGHTS_READ
    STANDARD_RIGHTS_WRITE
    STANDARD_RIGHTS_EXECUTE
    FlagsAndAttributes = 0x2000080
    FILE_ATTRIBUTE_NORMAL
    FILE_FLAG_BACKUP_SEMANTICS

###GetFileInfo 0054
GetFileInfo : c:/tmp/dokan\coo.max

###SetFileInfo 0054
SetEndOfFile c:/tmp/dokan\coo.max, 512
###SetFileInfo 0054
  SetAllocationInformation 512, can't handle this parameter.
###GetFileInfo 0054
GetFileInfo : c:/tmp/dokan\coo.max

###GetFileInfo 0054
GetFileInfo : c:/tmp/dokan\coo.max

###Lock 0054
LockFile c:/tmp/dokan\coo.max
    success

###Lock 0054
LockFile c:/tmp/dokan\coo.max
    success

###Lock 0054
UnlockFile c:/tmp/dokan\coo.max
    success

Original issue reported on code.google.com by coder...@gmail.com on 26 Feb 2009 at 9:30

[GoogleCodeExporter]

This is a problem of user-mode library.
The current version can't handle SetAllocationInformation correctly. I left some
comments on the source code.
We need to add SetAllocationInformation dispatch routine to DokanOperations,
so Dokan can handle it.

Original comment by asa...@gmail.com on 27 Feb 2009 at 8:25

[GoogleCodeExporter]

Hi Hiroki -

I tried to modify setfile.c::SetAllocationInformation() to just invoke 
setEndofFile()
by commenting out the "return 0" and that didn't work either.
My thinking was if setAllocationInformation sets the end of file to the 
requested
allocation size it will meet the requirement that the end-of-file position must
always be less than or equal to the allocation size. But that doesn't work. The
application (3dsmax) still hangs in the dokan call. We need to handle
setAllocationInformation correctly as you mentioned. This is critical for me do 
you
have any pointers on fixing this ? 

return DokanOperations->SetEndOfFile(
            EventContext->SetFile.FileName,
            allocInfo->AllocationSize.QuadPart,
            FileInfo);
  /*
    // How can we check the current end-of-file position?
    if (allocInfo->AllocationSize.QuadPart == 0) {
        return DokanOperations->SetEndOfFile(
            EventContext->SetFile.FileName,
            allocInfo->AllocationSize.QuadPart,
            FileInfo);
    } else {
        DbgPrint("  SetAllocationInformation %I64d, can't handle this parameter.\n",
                allocInfo->AllocationSize.QuadPart);
    }
    return 0;
  */

Original comment by coder...@gmail.com on 27 Feb 2009 at 7:38

[GoogleCodeExporter]

Also I further discovered that fileinfo.c::DispatchQueryInformation() does not
implement the case FileAllocationInformation. In general shouldn't Dokan have 
full
support for GetFileInformationByHandleEx classes ? These should be dispatched 
to the
user routines like other Dokan operations so they can choose to implement them. 
Are
there any hidden pitfalls to enhancing Dokan to support additional routines ?

Original comment by coder...@gmail.com on 27 Feb 2009 at 10:32

[GoogleCodeExporter]

Hello,

> My thinking was if setAllocationInformation sets the end of file to the 
requested
> allocation size it will meet the requirement that the end-of-file position 
must
> always be less than or equal to the allocation size. But that doesn't work. 
You are right. Dokan does not know the length of file, so Dokan can't handle 
allocation info correctly. We need to pass it to filesystem, in this case 
mirrofs, and filesystem have to handle allocation info.

GetFileInfo is called after SetAllocaitonInfo and my guess is the calller of
GetFileInfo checks the current size of file, but SetAllocationInfo didn't do 
nothing,
the size is wrong.

Original comment by asa...@gmail.com on 28 Feb 2009 at 9:08

[GoogleCodeExporter]

Hi Hiroki:

Also other serious problem associated with Dokan's end of file handling is,
SetFilePointer() is not separated from SetEndOfFile(). The mirror example
calls SetFilePointer() followed by SetEndOfFile(). When the application calls
SetFilePointer() , Dokan calls SetEndOfFile(). This appears to be not correct
and causes the application to not work.

Is there a reason why the SetFileOperation() can not be disptached to the 
user-land
Dokan driver?

Original comment by coder...@gmail.com on 2 Mar 2009 at 5:55