Wie kann man die Größe (frei, gesamt) des Telefonspeichers mithilfe der Nokia-API abrufen?

Question

Ich möchte die Größe des Telefonspeichers herausfinden. Ich benutze "Nokia-PC-Connectivity" und im Hinblick auf die File System API habe ich eine Funktion namens CONA_Folder_Info gefunden, aber diese Funktion unterstützt nicht FreeSize und Total Size. Es gibt jedoch CONA_Folder.Info2 und dessen Instanz unterstützt diese Variablen.

Aber als ich CONA_Folder.Info2 verwendete, wie folgt:

CONADefinitions.CONAPI_FOLDER_INFO2 FolderInfo;
int iResult = 0; // Speicherplatz für Buffer zuteilen
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) 
  {
  }

Bekomme ich diese Ausnahme:

Es wurde ein FatalExecutionEngineError festgestellt Nachricht: Das Runtime hat einen schwerwiegenden Fehler festgestellt. Die Adresse des Fehlers war bei 0x7a0ba769, im Thread 0x1278. Der Fehlercode ist 0xc0000005. Dieser Fehler kann ein Fehler im CLR oder in den unsicheren oder nicht überprüfbaren Teilen des Benutzercodes sein. Häufige Ursachen für diesen Fehler sind Benutzermarshalingfehler für COM-Interop oder PInvoke, die den Stack beschädigen können.

Hinweis: Ich benutze die S60-Softwareplattform. Die Anwendungssprache ist C#.

Für weitere Erklärungen fragen Sie mich bitte.

Answer 1

Es ist korrekt, dass Sie die Ausnahme erhalten, wenn Sie versuchen, die Daten im Puffer in eine andere Struktur umzuwandeln, als sie ursprünglich von CONAFileSystem.CONAFindNextFolder erstellt wurde.

Sie versuchen, eine Datenstruktur vom Typ CONADefinitions.CONAPI_FOLDER_INFO in eine Struktur vom Typ CONADefinitions.CONAPI_FOLDER_INFO2 zu zwingen. Sie haben höchstwahrscheinlich unterschiedliche Längen und so weiter, daher ist es äußerst unwahrscheinlich, dass diese Methode jemals funktionieren würde.

Aus Erfahrung mit der C++-Entwicklung unter dem Symbian OS besteht das Muster, das Nokia hier wahrscheinlich verwendet, darin, dass sie anschließend eine neuere Version der API entwickelt haben und daher eine neuere Version der CONADefinitions.CONAPI_FOLDER_INFO-Struktur erstellt haben (d. h. CONADefinitions.CONAPI_FOLDER_INFO2).

Vorausgesetzt, dies ist korrekt, gibt es 3 Wahrscheinlichkeiten:
1) Es gibt einen Enum-Parameter für die erste Funktion, der angibt, welche Version der Ausgabestruktur erstellt werden soll.
2) Es gibt eine neue Funktion, die die neue Struktur zurückgibt, z. B. CONAFileSystem.CONAFindFirstFolder2, CONAFileSystem.CONAFindNextFolder2
3) Nokia hat die neue Version intern entwickelt, aber noch nicht öffentlich freigegeben.

Answer 2

Ich weiß nichts über die Nokia API, aber im Allgemeinen sehe ich folgendes:

1. Find APIs haben normalerweise ein FindFirst, gefolgt von Iterationen von FindNext und dann ein FindClose. Ich sehe, dass Sie FindNext mit hFindHandle aufrufen, aber ich sehe nicht, dass es irgendwo initialisiert wird (was normalerweise in einem FindFirst-Aufruf passiert). Wenn dies Null ist, könnte das sicherlich eine Zugriffsverletzung verursachen.
2. Ohne mehr von Ihrer while() Schleife sieht es aus wie eine Endlosschleife - ich nehme an, Sie haben irgendwo anders noch ein FindNext?
3. Oft erfordern Find-Aufrufe, dass die eingehende Struktur initialisiert wird - wie das Setzen eines Längenmembers. Überprüfen Sie Ihre API-Dokumentation, um zu sehen, ob das hier erforderlich ist.
4. Ich sehe nicht, dass Sie Ihre Buffer-Variable freigeben oder den Such-Handle schließen (sofern er gültig ist).