tags:

views:

208

answers:

2

I want to get the size of the phone drive. I'm using "Nokia-PC-Connectivity"., and with respect to File System API I found on CONADifinition function called CONA_Folder_Info but this function doens't support FreeSize and Total Size but there is CONA_Folder.Info2 and its instance support these variables.

But when I used CONA_Folder.Info2 as follows:

CONADefinitions.CONAPI_FOLDER_INFO2 FolderInfo;
int iResult = 0;// Allocate memory for buffer
IntPtr Buffer = Marshal.AllocHGlobal(Marshal.SizeOf(typeof(CONADefinitions.CONAPI_FOLDER_INFO2)));                      
iResult = CONAFileSystem.CONAFindNextFolder(hFindHandle, Buffer);
while (iResult == PCCSErrors.CONA_OK )
{
  FolderInfo = (CONADefinitions.CONAPI_FOLDER_INFO2)Marshal.PtrToStructure(Buffer,    typeof(CONADefinitions.CONAPI_FOLDER_INFO2));
  if (FolderInfo.pstrName[0].ToString() != "C" && level == 0) 
  {
  }

I get this exception:

FatalExecutionEngineError was detected Message: The runtime has encountered a fatal error. The address of the error was at 0x7a0ba769, on thread 0x1278. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.

Note: I use the S60 software platform. Application language is C#.

For more explanations please ask me.

A: 

I don't know anything about the Nokia API, but in general I see the following:

  1. Find APIs usually have a FindFirst, followed by iterations of FindNext and then a FindClose. I see you calling FindNext with hFindHandle, but I don't see it getting initialized anywhere (which usually happens in a FindFirst call). If this is zero, that could certainly give an access violation.
  2. Without more of your while() loop it looks like an endless loop - I assume you have another FindNext somewhere?
  3. Often Find calls require that the incoming struct have some initialization done - like setting a length member. Check your API docs to see if that's required here.
  4. I don't see you freeing your Buffer variable or closing the find handle (assuming it's valid).
ctacke
all what you are saying is right and i do so and about my loop i just wrote the section that i do care about i dont have aprob. with FindNext and all u have mintioned, the part i'm interested in now is when i get the FolderInfo i have to options either to use CONA_Folder_Info or CONA_Folder_Info2
Eng.Basma
nobody has a background with CONA_Folder_Info or Nokia APIs ?!?! how bad luck :(
Eng.Basma
+1  A: 

It is correct that you get the exception when you try and convert the data in the buffer to a different type of structure than was originally created by CONAFileSystem.CONAFindNextFolder.

You are trying to force a data structure of type CONADefinitions.CONAPI_FOLDER_INFO into a structure of type CONADefinitions.CONAPI_FOLDER_INFO2. They almost certainly have different lengths and so on so its extremely unlikely this method would ever work.

From experience with C++ development on the Symbian OS, the pattern Nokia are likely to be using here is one where they have subsequently developed a newer version of the API and so have created a newer version of the CONADefinitions.CONAPI_FOLDER_INFO structure (i.e. CONADefinitions.CONAPI_FOLDER_INFO2).

Assuming this is correct there are 3 likelihoods:
1) There is an enum parameter to the first function which specifies which version of the output structure is to be created.
2) There is a new function which returns the new structure e.g. CONAFileSystem.CONAFindFirstFolder2, CONAFileSystem.CONAFindNextFolder2
3) Nokia have developed the new version internally but not yet released it publicly.

frankster