Datei von einem Verzeichnis in ein anderes kopieren (programmatisch)

Ich habe zur Aufgabe im Titel eine Verständnisfrage: wie kann man dabei vorgehen? Der Anfang ist klar:

1. Öffne Lese-Kanal und lies die ersten x (z.B. 256) Bytes der Datei aus in einen Puffer
2. Wechsle das Verzeichnis, öffne einen Schreibkanal und schreibe die 256 Bytes aus dem Puffer in die neue Datei

Jetzt wieder zum Lesen: muss ich in der Quelldatei jetzt wieder alle in 1. eingelesenen 256 Bytes nochmal einlesen um die neuen 256 Bytes danach einzulesen, oder kann ich den "Datenpointer" irgendwie an der Stelle belassen, an der ich aufgehört habe zu lesen? Die gleiche Frage stellt sich beim Schreiben in die Zieldatei.

Die Frage stellt sich natürlich nicht bei zwei verschiedenen SD2IECs an zwei verschiedenen Geräteadressen. Hier handelt es sich um die Situation mit einem einzigen SD2IEC.

Quote from muffi

Verständnisfrage: warum lässt Du nicht 2 Kanäle offen? Macht das SD2IEC keine 2 offenen Kanäle?

Natürlich würde ich zwei Kanäle benutzen, aber das SD2IEC hat (meines Wissens) ein CurrentDirectory. Wenn ich einen Kanal - sagen wir zum Lesen - öffne, und dann das Verzeichnis wechsle (mittels eines anderen Kanals), müsste doch die Referenz futsch sein. D.h., wenn ich dann mit dem ersten Kanal weiter lese, dürfte das nicht mehr funktionieren, weil er nicht weiß, wo er lesen soll. Oder verstehe ich da etwas grundsätzlich falsch?

Quote from muffi

gibt es evtl. die Möglichkeit, ähnlich wie bei CD eine Datei direkt anzusprechen, also etwa //dir/dateiname?

Ich habe gerade einiges ausprobiert und denke, dass das nicht der Fall ist.

Ja, das wurde schon mal diskutiert, aber estens weiß ich nicht mehr, wo, und zweitens kam dabei mMn heraus, dass ich auf jeden Fall hin und her springen muss. Klar kann ich ausprobieren, ob ich einfach weiter einlesen kann, aber ich habe auch nur begrenzt Zeit, und vielleicht hat hier jemand den Durchblick, wie ich prinzipiell vorgehen muss.

Ok, ich habe jetzt das Folgende (in BASIC) probiert:

1. Ins Verzeichnis "QUELLE" wechseln mit Kanal 15. Schließe Kanal 15.
2. Datei "WINGAMES,P,R" darin öffnen mit Kanal 3
3. Ins Root wechseln mit Kanal 15. Schließe Kanal 15.
4. Ins Verzeichnis "QUELLE" wechseln mit Kanal 15. Schließe Kanal 15.
5. GET#3,A$,B$:PRINT ASC(A$),ASC(B$):CLOSE3
6. Ins Root

Das gibt mir die Zahlen 71 und 13 aus, was falsch ist. Es müssten 1 und 8 sein, weil 0801 die Startadresse von WINGAMES ist (was auch passiert, wenn 5. anstelle von 3. ausgeführt wird). So geht es also nicht. Ich kriege zwar keinen OPEN ERROR, aber der Datenpointer scheint ganz woanders zu sein als am Start der Datei WINGAMES. Wie bekomme ich ihn wieder dahin?

darkvision Also müsste das folgende Programm funktionieren (aus Root heraus):

10 open 3,10,3,"//quelle/:WINGAMES,p,r"
20 open 4,10,4,"//ziel/:dest,p,w"
30 get#3,a$
40 if a$="" then a=chr$(0)
50 if ST<>0 then goto 80
60 print#4,a$;
70 goto 30
80 close 3:close 4

Klappt aber nicht. Der macht einen Durchlauf, geht zu 30 und freezed dann in Zeile 30.

Wenn ich Zeile 70 auskommentiere, schreibt er die 1 aus WINGAMES tatsächlich in das neue File. Aber es gibt darin danach noch ein zweites Byte: eine 13. Gut, vielleicht ist das normal.

Was bewirkt der Doppelpunkt vor dem Dateinamen?

Quote from darkvision

Quote from WebFritzi

Klappt aber nicht. Es gibt danach keinen Fehler, aber das SD2IEC blinkt rot, und nicht einmal das file "dest" wurde erstellt.

Da fehlt in Zeile 60 das abschließende ; sonst sendet jeder PRINT-Befehl ein zusätzliches CHR$(13).

Das hatte ich auch gerade bemerkt, danke.

Quote from darkvision

Quote from WebFritzi

Klappt aber nicht. Es gibt danach keinen Fehler, aber das SD2IEC blinkt rot, und nicht einmal das file "dest" wurde erstellt.

Aber beide Verzeichnisse sind vorhanden und die Ziel-Datei existiert noch nicht?

Und was sagt dann der Fehlerkanal, wenn er denn schon blinkt?

1. Frage: Genau
2. Frage: Mal sehen. Ich gebe unter JiffyDOS ein "@:10" un erhalte "00, OK, 00, 00", aber direkt danach (2 Zeilen drunter) nen SYNTAX ERROR. Keine Ahnung, was das zu bedeuten hat.

Es lag wohl an meinem Supersnapshot. Hab ich mal rausgemacht. Jetzt läuft er gerade. Scheint zu klappen. Aber mit nem Buffer (dann in Assembler) sollte es schneller sein, richtig?

Supergeil, vielen Dank, darkvision !!!

Nochmal die Frage: Was bewirkt der Doppelpunkt?

Quote from darkvision

Quote from WebFritzi

Es lag wohl an meinem Supersnapshot. Hab ich mal rausgemacht. Jetzt läuft er gerade. Scheint zu klappen. Aber mit nem Buffer (dann in Assembler) sollte es schneller sein, richtig?

Warum sollte es da schneller sein (mit Puffer, in Assembler geht es klar schneller)?

Keine Ahnung. Müsste man mal ausprobieren.

Ich habe das gleiche Programm übrigens mal zum Kopieren von Dateien zwischen Disketten in den Laufwerken 8 und 9 ausprobiert. Das klappt dann nicht. Er liest und schreibt erstmal ca. 60 Bytes, dann läuft das Programm weiter, aber die Laufwerke hören auf zu laufen. Dann irgendwann fängt das Laufwerkrauschen wieder an und hört wieder auf usw. Ein eingebauter Counter läuft die ganze Zeit weiter. Irgendwann - nach dem Kopieren von 4 Blocks (mal so, mal so) - ist dann Schluss. Sehr merkwürdig.

Quote from darkvision

Quote from WebFritzi

Nochmal die Frage: Was bewirkt der Doppelpunkt?

Gegenfrage: Was passiert wenn Du den Doppelpunkt weg lässt

Ich bekomme ein FILE NOT FOUND ERROR. Frage ist: warum? Ist deine Antwort "Isso", oder kann man das logisch erklären?

Ich habe das mal versucht, ohne Puffer in Assembler zu realisieren (erstmal für 2 Disk-Laufwerke). Für kleine Dateien mit bis zu 5 Blocks funktioniert das auch wunderbar, aber bei größeren (ca. 40 Blocks) kommt der nicht zum Ende. Vielleicht kommt der durch das andauernde Wechseln irgendwie aus dem Takt. Hier der Code:

-               ldx #$03      ; filenumber 3
                jsr CHKIN     ; file 3 now used as input
                ; Read a byte from source
                jsr CHRIN     ; get a byte from file
                sta $AE       ; write byte to memory
                jsr READST
                bne copy_eof  ; either EOF or read error
                jsr CLRCHN
                ; Write byte to destination
                ldx #$02      ; filenumber 2
                jsr CHKOUT    ; file 2 now used as output
                lda $AE       ; get byte from memory
                jsr CHROUT    ; write byte to file
                jsr READST
                bne writeerror; write error
                jsr CLRCHN
                jmp -
copy_eof        and #$40
                beq copy_readerror
                ; End of file, write last bytes to dest file
                ldx #$02      ; filenumber 2
                jsr CHKOUT    ; file 2 now used as output
                lda $AE       ; get byte from memory
                jsr CHROUT    ; write byte to file
                jsr READST
                bne writeerror; write error
copy_close      jsr CLRCHN
                lda #$03      ; filenumber 3
                jsr CLOSE
                lda #$02      ; filenumber 2
                jmp CLOSE

Ok, egal. Ich mach's mit dem Puffer, und fertig.

Anderes Problem: Was, wenn eine der Dateien (oder beide) nicht in einem Verzeichnis, sondern in einem Disk-Image liegt? Versuche mit

open 3,10,3,"//my games/tetris.d64/:tetris,p,r"

oder

open 3,10,3,"//my games/tetris.d64:tetris,p,r"

liefen leider in's Leere.

EDIT: Aha. Wir haben das Please login to see this link. schon mal besprochen. Da war der Tenor, dass ich zwischen den Images hin und her wechseln muss. Und da stellt sich wieder die Frage nach dem "Datenzeiger", zu dem ich nicht in jedem Durchgang immer wieder hinspringen möchte.

EDIT2: Was mit der obigen Methode gehen würde/könnte:
Von Image nach Directory: Ins Image navigieren und das Quell-File ohne Pfad angeben.
Von Directory nach Image: Ins Image navigieren und das Ziel-File ohne Pfad angeben.
Von Image nach Image: Erst ins Root kopieren,dann von da in das Ziel-Image und schließlich die Dummy-Datei im Root wieder löschen. Dauert dann halt doppelt so lange.