Shfileoperation vor jedem Kopiervorgang einer Datei ein fall abfragen

[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:

fromDir + #0

Delphi hängt implizit eine #0 an alle Strings an.
Also Ende ist immer #0#0.
Listen sind durch #0 getrennt.
PChar('Datei1' + #0 + 'Datei2' + #0 + 'Datei3' + #0 + #0{diese Letzte kann man, muß man aber nicht})

[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 von nahpets:

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.


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 von nahpets:

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

[himitsu]

Zitat von DeddyH:

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.

[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.