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:

[timmbo]

Danke.

Zitat:

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

Sorry habs falsch erklärt. Ich meinte das der Fehler zwar kommt aber dann weitergemacht wird. Somit wird die Datei übersprungen und somit nicht kopiert.

Hauptsächlich ging es um das zweite problem das bei jedem Kopiervorgang einer Datei noch eine Abfrage gemacht werden kann.Ich habe gehofft das es dafür schon etwas geben würde. Komme also nicht daran vorbei eine eigene Funktion zu erstellen und jede Datei einzeln zu Kopieren. Dann kann ich so viele Abfragen machen wie ich will. Danke Für die hilfe:thumb:

[himitsu]

Zitat:

Zitat von DeddyH (Beitrag 1358673)

Mit irgendwelchen Zeitstempeln herumzuhantieren ist da wesentlich fehleranfälliger.

Delphi nimmt die Local-LastWriteTime zur Prüfung, ob geöffnete Dateien extern verändert wurden.
Immer zur Zeitumstellung (Sommer-/Winterzeit) meckert Delphi dann plötzlich rum, dass alle Dateien angeblich geändert wurden. :stupid:

[nahpets]

@a.def

Das kannst Du halten wie Du willst, aber ich halte das nicht für ein sinnvolles vorgehen.

Nach Deinen Vorstellungen dürftest Du dann jedenfalls keine professionelle Datensicherungssoftware nutzen.

Abgesehen davon hat das Archiv-Bit nichts, aber auch garnichts mit irgendeiner Eingabe vom Benutzer zu tuen. Es ist eine Funktionalität des Betriebsystemes.

Falls Du deren korrekte Nutzung anzweifelst, solltest Du Dich auch nicht auf den Zeitstempel verlassen, der wird auch vom Betriebssystem bei 'ner Änderung gesetzt.

Mir erschließt sich nicht, was das mit dem Benutzer und seinen Eingaben zu tuen haben soll und warum man sich auf den vom Betriebssystem gesetzten Zeitstempel verlassen kann, aber nicht auf das zum gleichen Zeitpunkt vom Betriebssystem gesetzte Attribut zur Kennzeichnung einer Änderung.

Das Archiv-Bit wird doch gerade deshalb vom Betriebssystem gesetzt, damit man Änderungen an Dateien erkennen kann, ohne einen (wie auch immer gearteten) Vorher-/Nachhervergleich machen zu müssen.

Den Zeitstempel kann man einsetzem, wenn man alle Dateien sichern will, die neuer als ein zu wählender Zeitpunkt sind.

Das heißt aber nicht, dass man damit alle seit der letzten Sicherung geänderten Dateien sichert, sondern dass man alle neueren Dateien sichert.
Da mag es dann eine Schnittmenge geben, aber man hat nicht sicher alle geänderten Dateien, sondern nur die nach dem Zeitpunkt geänderten oder neuerstellten Dateien.

Nutzt man das Archiv-Bit, so muss man den Zeitpunkt der letzten Sicherung nicht wissen.
Alles mit gesetztem Archiv-Bit wurde geändert bzw. neu erstellt und ist damit zu sichern.
Selbst bei einer massiven Umstellung von Systemzeit und Datum funktioniert die Sicherung unter Zuhilfenahme des Archiv-Bits noch verlässlich.

Siehe hierzu himitsu Anmerkung.

Oder nimm Deinen Laptop mal mit auf Reise und ändere die Zeitzone entsprechend den örtlichen Gegebenheiten. Und, je nach West- oder Ostreiserichtung, hast Du dann auf einmal eine Zeitlücke, die entweder zu doppelter oder zu fehlender Sicherung von Dateien führen kann.
(Die, abhängig von der Reisegeschwindigkeit, größer oder kleiner sein kann - siehe "In 80 Tagen um die Welt" von Jules Verne ;-))

Mit dem Archiv-Bit ist das schnurz, das funktioniert weiterhin.

[a.def]

Ich habe gestern mal ein bisschen mit dem Archivbit und CopyFileEx usw rumprobiert.
Muss man das Bit selber entfernen? Denn in meinen Tests hat weder CopyFileEx noch die SHFileOperations das Bit entfernt.

[Luckie]

Ja, muss man. Nur das Konsolenprogramm xcopy setzt das Archivbit zurück, wenn gewünscht.