Shfileoperation vor jedem Kopiervorgang einer Datei ein fall abfragen

[timmbo]

Hallo,
Ich bin gerade dabei ein kleines Programm zu programmieren, dass mir meine Daten täglich sichert. Dies mach ich mit hilfe der SHFileoperation. Jetzt bin ich nur auf zwei Probleme gestoßen.

function CopyDir(const fromDir, toDir: string): Boolean;
var
fos: TSHFileOpStruct;
begin
ZeroMemory(@fos, SizeOf(fos));
with fos do
begin
//showmessage('test');
wFunc := FO_COPY;
fFlags := FOF_FILESONLY or FOF_RENAMEONCOLLISION or FOF_NOCONFIRMATION;
pFrom := PChar(fromDir + #0);
pTo := PChar(toDir)
end;
Result := (0 = ShFileOperation(fos));

end;

1. Falls eine Datei zu lang zum kopieren sein sollte, stoppt das programm, bis ich einen weiteren Befehl eingebe. Es ist zwar möglich, mit der flag "FOF_NOCONFIRMATION" den Befehl zu ignorieren. aber dann wird, die zu lange Datei nicht kopiert.
2. Ich hätte gerne das meine Software z.b wenn ich täglich sichere Montags ein VollBackup macht und an den weiteren Tagen in der Woche nur noch Daten kopiert die verändert wurden.

Beide könnte ich lösen indem ich, jedes mal bevor ich eine Datei kopiere, zwei abfragen machen könnte. Aber leider habe ich keine lösung. Kennt vielleicht jemand eine Alternative oder hat eine ahnung wie die shfileoperation aufgebaut ist, damit ich sie bearbeiten kann.

Vielen Dank

[a.def]

Zu 1:
was heißt "zu lang"? Wie lautet die Fehlermeldung?

Zu 2:
dabei wird dir hier in diesem Thread wohl keiner helfen können denn das ist ein "bisschen mehr" Aufwand als du denkst.

Mit shfileoperation wirst du hier so wie du es verwendest nicht weit kommen.
Du müsstest eine Dateiliste anlegen von Quelle und Ziel und dann die Daten vergleichen.

[himitsu]

"Zu lang" bezieht sich auf den Dateipfad/Verzeichnisnamen?

Ansonsten wird immer "Ja" verwendet, wenn man die Userrückfrage abschaltet.
Außer natürlich bei "Fehlermeldungen", welche dabei unterdrückt werden würden, aber FOF_NOCONFIRMATION sollte nur "Ja/Nein"-Fragen automatisch beantworten, aber keine Fehler "blind" unterdrücken. :grueble:


2.) ShFileOperation kann/unterstützt nicht sowas, wie z.B. beim XCOPY, wo man sagen kann "kopiere nur wenn ArchivFlag gesetzt und setze das Flag anschließend zurück".
Also, wie bereits gesagt, entweder Datei für Datei selber kopieren (TFile.Copy/CopyFile/CopyFileEx/ShFileOperation)
oder eine FileListe zusammenstellen und an ShFileOperation übergeben.


Auch bei ToDir muß die #0 dran.

Zitat:

Delphi-Quellcode:

fromDir + #0

Delphi hängt implizit eine #0 an alle Strings an.
Also Ende ist immer #0#0.
Listen sind durch #0 getrennt.

Delphi-Quellcode:

PChar('Datei1' + #0 + 'Datei2' + #0 + 'Datei3' + #0 + #0{diese Letzte kann man, muß man aber nicht})

[nahpets]

Dafür gibt es eigentlich das Archiv-Bit.

Bei 'ner Vollsicherung sichert man alle Dateien und setzt bei allen Dateien das Archiv-Bit zurück.

Bei 'ner Teisicherung prüft man, ob das Bit gesetzt ist und sicherte eine Datei bei gesetztem Bit. Das Bit wird zurückgesetzt.

Damit kann man beide Sicherungen, ohne großen Aufwand mit Listenvergleichen ..., durchführen.

Macht eigentlich jede Sicherungssoftware so.

[a.def]

Das Problem mit zu langen Pfadangaben hatte ich auch mal. Das wird aber erst ein Problem, wenn der Pfad wirklich ... wirklich ... zu lang ist und das bemerkt man schnell.

Zitat:

Zitat von nahpets (Beitrag 1358667)

Dafür gibt es eigentlich das Archiv-Bit.

Oder man vergleicht die Zeitstempel. Dann braucht man nicht in den Dateien rumzuwerkeln.

[himitsu]

SHFILEOPSTRUCT

Zitat:

FOF_NOCONFIRMATION : Respond with Yes to All for any dialog box that is displayed.

FOF_NOERRORUI : Do not display a dialog to the user if an error occurs.

Wie ich's mir dachte ... Fehler sollten bei deinem geposteten Code nicht einfach verschwinden. :gruebel:


PS: Es wäre nett, wenn du deinen post editierst und das fehlende [DELPHI]dein Code[/DELPHI] einfügst, damit man den Code besser lesen kann.

[nahpets]

@a.def

Wieso "in den Dateien rumwerkeln"?

Das Archiv-Bit wird vom Betriebssystem gepflegt, es ist ein Teil des Verzeichniseintrages im Dateisystem.

Bei meinem ollen XP wird es im Explorer in der Spalte Attribute als "A" angezeigt, sofern es gesetzt ist.

Können das neuere Windosen nicht mehr?

Womit soll ich denn den Zeitstempel vergleichen, dann muss ich ja alle Informationen der vorhergehenden Datensicherung haben und da jeweils suchen?

Warum? Das Archiv-Bit ist die vom Betriebssystem für die Kenntlichmachung geänderte Dateien vorgesehene Informationquelle. Wird eine Datei geändert, so wird bei der Änderung vom Betriebssystem das Archiv-Bit gesetzt.
Warum soll man denn dann irgendeine andere Lösung zur Erkennung einer Änderung nutzen, wenn das Betriebssystem diese Kennung automatisch liefert?

[a.def]

Zitat:

Zitat von nahpets (Beitrag 1358670)

Warum soll man denn dann irgendeine andere Lösung zur Erkennung einer Änderung nutzen, wenn das Betriebssystem diese Kennung automatisch liefert?

Ich habe damals gelernt, dass man immer den dümmsten anzunehmenden Benutzer vor einer Software sitzen haben kann. Und gute Software versucht so ziemlich jede Falscheingabe zu reparieren.
Man muss doch eh eine Dateiliste erstellen und hat dann jegliche Informationen zu jeder Datei. Da berufe ich mich dann lieber auf die Zeitstempel als auf ein Archivbit.

[DeddyH]

Welche Falscheingabe soll denn ein Dateiattribut zurücksetzen? Das Archivbit ist schon seit DOS-Zeiten genau dafür gedacht, kenntlich zu machen, dass eine Datei geändert wurde. Mit irgendwelchen Zeitstempeln herumzuhantieren ist da wesentlich fehleranfälliger.

[a.def]

(Beitrag #10) http://www.delphipraxis.net/1186883-post10.html :thumb: