4. txt-Datei kopieren

txt-Datei kopieren

  • B

    Hi

    ich hab folgendes Problem:
    ich habe eine txt-Datei, in der 10 Dateipfade drinstehene, also sie sieht so aus:

    c:\0.mp3
    c:\1.mp3
    c:\2.mp3
    c:\3.mp3
    c:\4.mp3
    c:\5.mp3
    c:\6.mp3
    c:\7.mp3
    c:\8.mp3
    c:\9.mp3

    jetzt möchte ich diese in eine andere kopieren. Hab es schon versucht, aber das hat nicht geklappt.

    Danke

    0
  • D

    wenns nicht geklappt hat, ist wohl ein Fehler drin

    Was willst du jetzt wissen? Wie man Dateien kopiert?
    Da machst du
    int ch;
    while((ch=fgetc(quelldatei) != EOF ) fputc(ch,zieldatei);

    0
  • J

    Da es sich um binäre Dateien handelt ist vermutlich fread und fwrite nicht nur schneller sondern auch die einzige Variante die wirklich funktioniert.

    -junix

    0
  • S

    Original erstellt von junix:
    **Da es sich um binäre Dateien handelt ist vermutlich fread und fwrite nicht nur schneller sondern auch die einzige Variante die wirklich funktioniert.

    -junix**

    es handelt sich aber um eine textdatei!

    Trotzdem waere fread und fwrite schneller, oder zumindest fgets/fputs - denn eine groessere Datei mit fgetc/fputc zu kopieren kann dauern...

    0
  • B

    Ok, ich versuch es nochmal besser zu erklären:

    ich habe die txt-Datei, in der die 10 Pfade stehen (siehe oben)
    In meine Funktion übergebe ich einen weiteren Pfad. Nun sollen alle, bis auf den ersten Pfad in eine temporäre-Datei geschrieben werden. und als letztes noch der übergebene Pfad. Anschliesend wird die ursprüngliche Datei gelöscht und der Inhalt der temporären soll dorthin kopiert werden.

    Hier mal mein Code, der leider nicht geht:

    int open_dat(char *sz_pfad)
{
    FILE *datei1, *datei2;
    int i;
    char buffer[FILENAME_MAX] = { 0 };
    datei1 = fopen("mp3s.txt","r");
    datei2 = fopen("temp.txt","w+");
    fseek(datei2,0, SEEK_SET);
    for(i=0; i<9; i++)
    {
        fgets(buffer, FILENAME_MAX, datei1); //Zeilenweise einlesen der Dateipfade
        buffer[sizeof(buffer)-1] = '\n';
        if (i > 0)
            fputs(buffer,datei2);
    }
    sz_pfad[sizeof(sz_pfad)-1] = '\n';
    fputs(sz_pfad,datei2);
fclose(datei1);
datei1 = fopen("mp3s.txt","w+");
fseek(datei1,0, SEEK_SET);
for(i=0; i<9; i++)
    {
        fgets(buffer, FILENAME_MAX, datei2); //Zeilenweise einlesen der Dateipfade
            fputs(buffer,datei1);
    }
fclose(datei1);
fclose(datei2);
//remove( "temp.txt" );
return 0;
}

    Was sit falsch?

    Danke

    0
  • R

    1. verstehe ich nicht den Sinn von fseek. Wenn du die Dateien öffnest, sind die doch auf SEEK_SET gesetzt (also auf den start) (ausnahme ist natürlich "a", wo der Stream auf SEEK_END gesetzt ist :)) und wenn würde ich rewind nehmen, da das noch schneller sein kann als fseek(stream,0L,SEEK_SET) oder zumindest genauso schnell ist

    2. liest fgets doch mit abschließendem \n. Warum setzt du dann noch einmal \n?

    3. und dann schau dir mal an was sizeof(sz_pfad) zurückgibt 🙂

    0
  • B

    aha, hab es geändert. Geht aber trotzdem nicht.

    Hier der aktuelle Code

    int open_dat(char *sz_pfad)
{
    FILE *datei1, *datei2;
    int i;
    char buffer[FILENAME_MAX] = { 0 };
    datei1 = fopen("mp3s.txt","r");
    datei2 = fopen("temp.txt","w+");
    for(i=0; i<9; i++)
    {
        fgets(buffer, FILENAME_MAX, datei1); //Zeilenweise einlesen der Dateipfade
        if (i > 0)
            fputs(buffer,datei2);
    }
    fputs(sz_pfad,datei2);
fclose(datei1);
datei1 = fopen("mp3s.txt","w+");
for(i=0; i<9; i++)
    {
        fgets(buffer, FILENAME_MAX, datei2); //Zeilenweise einlesen der Dateipfade
            fputs(buffer,datei1);
    }
fclose(datei1);
fclose(datei2);
//remove( "temp.txt" );
return 0;
}
    0
  • S

    nimm mal FILENAME_MAX raus - das hat ja nix mit einer zeilenlaenge zu tun...

    und dann erklaer mal wo es genau hapert - was macht er, bzw. was macht er nicht?

    0
  • B

    Was es macht: in die Temporäre Datei kopieren klappt fast.

    c:\lenny.mp3
    c:\lenny.mp3
    c:\lenny.mp3
    c:\lenny.mp3
    c:\lenny.mp3
    c:\lenny.mp3
    c:\lenny.mp3
    c:\lenny.mp3
    c:\
    ock.mp3ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ(das geht immer so weiter)

    das letzte sollte auch c:\rock.mp3 heissen (eigentlich)

    Und die neue mp3s.txt sieht dann nur noch son aus:

    ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ(geht immer so weiter)

    0
  • S

    schliesse einfach alle dateien nach der ersten schleife, und oeffne dann die dateien neu die du fuer die 2. schleife brauchst!

    ist es beabsichtig, dass du immer nur 9 zeilen liest?

    sz_pfad[sizeof(sz_pfad)-1] = '\n';
    das ist kaese!

    sizeof sz_pfad == sizeof char*
    was auf 32bit systemen 4 entspricht!
    was du brauchst ist wohl strlen()

    0
  • D

    Original erstellt von junix:
    **Da es sich um binäre Dateien handelt ist vermutlich fread und fwrite nicht nur schneller sondern auch die einzige Variante die wirklich funktioniert.
    **

    Geschwindigkeit klingt logisch.
    Aber wieso sollte das nicht bei Binärdateien funktionieren?

    0
  • P

    hmm weis nicht obich das problem richtig verstanden habe....du hast eine txt file mit text drin und willst eine zweite txt file erstellen?

    wenn dem so ist dann mach das doch einfach mit dem system("");
    in die gänsefüsschen setzt du dann einfach ms-dos befehle rein. wie zum beispiel xcopy. mit dem eine datei kopiert wird 🙂

    0
  • S

    Original erstellt von Peter Piksa:
    wenn dem so ist dann mach das doch einfach mit dem system("");
    in die gänsefüsschen setzt du dann einfach ms-dos befehle rein. wie zum beispiel xcopy. mit dem eine datei kopiert wird 🙂

    Sag mal großer Meister, du willst doch etwa nicht alle Nicht-DOS-Benutzer ausgrenzen, oder?

    system ist nicht nur lahm, sondern hat auch noch implementation definied behaviour!

    0
  • D

    system ist weder lahm, noch hat es implementierungsspezifisches Verhalten.
    Die Norm macht keine Angaben über die Geschwindigkeit von Funktionen (nicht mal C++ macht das ;)), zum anderen sehe ich nicht, was z.B. an 'system(0)' so implementierungsspezifisch ist; der Rückgabewert hängt von der Umgebung ab, aber das ist trotzdem kein implementierungsspezifisches Verhalten.

    Aber wieso sollte das nicht bei Binärdateien funktionieren?

    Diese Methode funktioniert allgemein nicht zuverlässig, unabhängig von Binärdateien: Auf Systemen bei denen der int-Bereich genau so groß wie der (unsigned) char-Bereich ist kann irgendein legales Zeichen die Bit-Repersentation für EOF (ein negativer Wert) erhalten. Die Schleife terminiert also, obwohl noch kein feof noch kein Ende und ferror noch keinen Fehler gefunden hat. Dieser Einwand ist aber IMHO an einigen Haaren herbeigezogen aber im Rahmen der ISO-Norm wäre ein solches System gültig.

    [ Dieser Beitrag wurde am 17.12.2002 um 17:02 Uhr von Daniel E. editiert. ]

    0
  • P

    Meine fresse - ich bin nichtmal 15 stunden in diesem thread nicht mehr gewesen und schon peil ich nichtsmehr! lol

    0
  • M

    Original erstellt von Daniel E.:
    [QB]...
    Diese Methode funktioniert allgemein nicht zuverlässig, unabhängig von Binärdateien: Auf Systemen bei denen der int-Bereich genau so groß wie der (unsigned) char-Bereich ist kann irgendein legales Zeichen die Bit-Repersentation für EOF (ein negativer Wert) erhalten. Die Schleife terminiert also, obwohl noch kein feof noch kein Ende und ferror noch keinen Fehler gefunden hat. Dieser Einwand ist aber IMHO an einigen Haaren herbeigezogen aber im Rahmen der ISO-Norm wäre ein solches System gültig. ...

    Auf einem solchen System kann diese Schleife abhilfe schaffen:

    while ( (ch=fgetc(quelldatei)) != EOF || !feof(quelldatei) ) fputc(ch,zieldatei);

    😉

    0
  • S

    Original erstellt von Peter Piksa:
    Meine fresse - ich bin nichtmal 15 stunden in diesem thread nicht mehr gewesen und schon peil ich nichtsmehr! lol

    was ist dir denn unklar??

    0
  • ?

    Erklär mal bitte "Implementation defined behaviour", bzw was damit gemeint ist.

    0
  • S

    Original erstellt von <sg>:
    Erklär mal bitte "Implementation defined behaviour", bzw was damit gemeint ist.

    Im Standard und auch FinalDraft steht das drinnen!

    Implementation defined behavior heisst, dass der Standard nicht vorschreibt wie die Implementierung (also Compiler und Library) auf so etwas reagieren. Allerdings muss die Implementierung ihr verhalten diesbezüglich offen legen.

    zB system("dir") - das wird dir unter Unix nicht viel bringen!

    0
  • F

    Original erstellt von Bernd_K:
    **

    ...
c:\lenny.mp3
c:\
ock.mp3ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ(das geht immer so weiter)
...

    **

    völlig logisch, dass du '\r' nicht in eine Textdatei schreiben kannst! das wird automatisch konvertiert (Carriage Return = Wagenrücklauf)
    auch wenns ne Textdatei ist, ists sicher kein fehler das File wie ne Binärdatei zu kopieren

    0
Anmelden zum Antworten