[HELP] Files kopieren :: Zugriffsverletzung

Midnighter

Hi Andreas,

ich danke Dir,
ich werd mir das nochmal alles genauer anschauen müssen und vielleicht noch ein paar Daten mehr sammeln, von den Leuten, bei denen es nicht geht.

Thanks anyway!
mid

AndreasW

Ich schiebe diese mal nach API. Vieleicht haben die dort noch Lösungsansätzte.

WebFritzi

In allen 3 Versionen hast du sowas:

(*(orgName + i)).c_str()

Daran liegt es ganz bestimmt. Du übergibst also 2 dynamisch angelegte AnsiString-Arrays mit der Länge runs. Hmm, versuch mal lieber sowas wie

orgname[i].c_str()

Sieht mir sicherer aus.

AndreasW

(*(orgName + i)).c_str(),

ohje, hab ich glatt übersehen...

WebFritzi

Aber eigentlich müsste es ja das gleiche sein. Nur wer weiß, wie Borland genau die Klasse AnsiString implementiert hat. Ich weiß nur, dass die Klasse basierend auf Assembler-Code geschrieben wurde. Naja, ich habe jedenfalls kein gutes Gefühl, wenn ich diese Zeigeroperation da sehe.

Midnighter

Hi Leute,

Ich änder das mal ab.
Das seltsame ist halt nur, dass es bei 99,5 Prozent der Fälle klappt.
Mal schauen was wird.

Danke!

WebFritzi

Huups, da habe ich eine Idee. Wie wäre es, mit TStringList zu arbeiten:

// Funktion fCopy()
bool fCopy(TStringList* orgNames, TStringList* bakNames)
{
   if(!orgNames || !bakNames)
      return false;

   if(orgNames->Count != bakNames->Count)
      return false;

   FILE *fp1, *fp2;
   unsigned int c;

   for (int i=0; i<orgNames->Count; i++)
   {
      // Dateien öffnen
      fp1 = fopen(orgNames->Strings[i].c_str(), "rb");
      fp2 = fopen(bakNames->Strings[i].c_str(), "wb");

      // Dateiinhalte kopieren
      while (  ( c = getc(fp1) ) != EOF  )
          putc( c, fp2 );

      // Dateien schließen
      fclose(fp1);
      fclose(fp2);
   }

   return true;
}

Das ist das Sicherste!

[ Dieser Beitrag wurde am 10.03.2003 um 00:18 Uhr von WebFritzi editiert. ]

Midnighter

Danke für den Klasse Tip Fritzi, ich werde das mal einbauen und an so nen Problemfall schicken.

Aber mal noch was anderes zu dieser "Zeigeroperation" *smile*

files = ( AnsiString * ) calloc ( anzMets, MAX_PARTMET_FILENAME_LENGTH );
files = ( AnsiString * ) calloc ( anzMets, MAX_PARTMET_FILENAME_LENGTH );

Meine MAX_PART... hab ich mit 15 definiert.

Nehmen wir an, ich finde 500 Files mit meinem FindFirst/-Next.
Die 500 steht dann in anzMets.
Das ergibt doch bei meinen Mathe-Kentnissen 7500. Wenn ich nun bei den überwachten Ausdrücken *(files + 6000) angebe, dann sollte doch da NULL oder ein Filename auftauchen. Ab *(files + 4500) etwa steht nicht mehr NULL da, wenn noch nix reingeschrieben ist, sondern ????. Ist das so ein Anzeichen, was Du meintest in Bezug auf Ansistring und meine Zeigerspielchen ?

Falls ja, dann sollte ich mich wohl davon distanzieren, sowas zu tun.

greetz,
mid

WebFritzi

Original erstellt von Midnighter:
Ist das so ein Anzeichen, was Du meintest in Bezug auf Ansistring und meine Zeigerspielchen ?

Nö. Das ist ganz normal. Du allokierst ja Seicher, und da kann alles drin stehen. Aber mir wird jetzt einiges klar. Du benutzt für jeden AnsiString pauschal 15 Bytes. Bei den Problemfällen wird es wohl so sein, dass es genug Files gibt, deren Pfade lang genug sind, so dass der AnsiString mehr als 15 Bytes umfasst. Wir arbeiten nicht umsonst mit dem C**++**Builder. Deshalb benutzen wir new. Wenn du also schreiben würdest

AnsiString* files;
files = new AnsiString[anzMets];

würde alles gutgehen. Ich plädiere trotzdem für den Einsatz von TStringList, denn genau für sowas ist diese Klasse da.

Midnighter

Original erstellt von WebFritzi:
Ich plädiere trotzdem für den Einsatz von TStringList, denn genau für sowas ist diese Klasse da.

Jepp, das habe ich auch soeben so ähnlich, wie Du gepostet hast implementiert. Hab nur zum Kopieren weiterhin WinAPI-Funktionen verwendet.

Hab mir damit ne Zählvariable gespart und ne Menge verschenkten Speicher, weil ich wegen dem ganzen Kram schon mit dem Gedanken gespielt habe, einige Array statisch zu machen.

Thx, dass Du mich an dem wirklich super Einfall hast teilhaben lassen!

N8,
mid