Informationen zur Funktionsweise

Übersicht

Für alle diejenigen, die sich für tiefer gehende Details interessieren, habe ich nachfolgend einige Informationen zusammengestellt.

• Unicode-Zeichensatz
• Kennwörter
• Verwendung der Windows-Aufgabenplanung
• Kopieren von Dateien
• Komprimieren als GZip
• Erstellen von Zip-Archiven
• Verschlüsselung
• Länge von Dateipfaden
• Backups beim Abmelden/Herunterfahren

Unicode-Zeichensatz

Seit Vers. 5.0 wird Personal Backup mit einer Entwicklungsumgebung erstellt, die den Unicode-Zeichensatz unterstützt (aktuell Delphi 10 Seattle). Damit gehören die Beschränkungen des ANSI-Zeichensatzes (ISO-8859) bei Dateinamen der Vergangenheit an. Außerdem sind jetzt Pfadlängen von mehr als 260 Zeichen erlaubt.

Die wichtigsten Merkmale:

• Anzeige von Datei- und Verzeichnisnamen mit nicht ISO-8859-Zeichen (z.B. griechisch oder kyrillisch)
• Sicherung solcher Dateien auch als GZip und Zip
• Sicherung solcher Dateien auch über FTP, sofern der Server UTF-8 unterstützt
• Mailversand im UTF-8-Format
• Protokollierung im UTF-8-Format
• Sicherung, Wiederherstellung, Überprüfung und Löschen von Dateien auch bei Pfadlängen > 260 Zeichen

Kennwörter

Alle Kennwörter, sowohl für FTP, SMTP als auch AES-Verschlüsselung müssen in der Kodierung ISO-8859-1 angegeben werden, d.h. es sind auch Umlaute erlaubt.

Verwendung der Windows-Aufgabenplanung

Seit Windows 7 gibt es eine neue Version 2.0 der Aufgabenplanung. Diese umfasst neben den Funktionen der Vorversion auch einige neue Optionen, z.B. das Nachholen einer Aufgabe oder das Verwenden eines Benutzerkontos ohne Angabe eines Kennworts.
Die aktuelle Version von Personal Backup unterstützt im integrierten Assistenten nur diese neue Version der Windows-Aufgabenplanung. Auf Systemen mit Windows XP steht diese Funktion daher nicht mehr zur Verfügung.

Das Kopieren einer Datei, z.B. test.dat, erfolgt in mehreren Schritten:

• <Quelle>\test.dat wird nach <Ziel>\test.dat.tmp kopiert.
• Wenn das erfolgreich war:
  • <Ziel>\test.dat wird gelöscht.
  • <Ziel>\test.dat.tmp wird in <Ziel>\test.dat umbenannt.
• Wenn das nicht erfolgreich war, wird die Datei <Ziel>\test.dat.tmp gelöscht und eine Fehlermeldung generiert.

Das wird gemacht, um eine bereits im Ziel vorhandene Datei nicht sofort zu überschreiben, sondern erst, wenn das Kopieren erfolgreich war. Damit bleibt im Ziel bei einem Kopierfehler die Vorversion erhalten.

Dieses Verfahren erfordert natürlich entsprechend freien Platz auf dem Ziellaufwerk. Bei normalen Dateigrößen ist das i.d.R. kein Problem. Bei sehr großen Dateien kann es allerdings zu Problemen führen. Es wird dann beim Kopieren der Fehler gemeldet, dass nicht mehr genügend freier Platz auf dem Ziellaufwerk vorhanden ist.

Komprimieren als GZip

Dateinamen

Der existierende Standard für das gzip-Format (RFC1952 von 1996) legt fest, dass der Dateiname im ISO-8859-1-Zeichensatz gespeichert werden soll. Ich habe leider keine allgemein gültigen Festlegungen gefunden, wie mit Unicode-Dateinamen umzugehen ist.

So weicht z.B. die aktuelle Linux-Version des Programms GZip, mit dem gz-Archive erzeugt und gelesen werden können, von diesem Standard ab und speichert den Dateinamen im UTF-8-Format. Dabei wird das OS-Byte im Header auf 3 (Unix) gesetzt.

Um hier möglichst kompatibel zu bleiben, verfährt Personal Backup ab Vers. 5.0 wie folgt:

• Der Dateiname enthält nur Zeichen, die zum westeuropäischen Zeichensatz (Latin-1) gehören: OS = 0 (FAT) => Dateiname wird als ISO-8859-1 gespeichert
• Der Dateiname enthält auch andere Zeichen: OS = 11 (NTFS) => Dateiname wird als UTF-8 gespeichert

Damit ergibt sich allerdings das Problem, dass Fremdprogramme (wie z.B. WinZip oder WinRar) die von Personal Backup in den gz-Dateien gespeicherten Dateinamen nur im ersten Fall richtig erkennen. Auf das Entpacken hat das allerdings keinen Einfluss.

Besser wäre es sicherlich das z.Zt nicht benutzte Bit 5 des FLG-Byte als Unterscheidungsmerkmal für die Kodierung zu benutzen. So ähnlich wird es z.B. beim Zip-Format (s.u.) gemacht.

Dateien ≥ 4 GB

Im existierenden Standard für das gzip-Format (RFC1952 von 1996) ist für die Größe der unkomprimierten Datei nur ein 32-bit-Wert vorgesehen. Bei Dateien ≥ 4 GB wird dieser Wert dann modulo 2³² geschrieben. Viele Packprogramme (wie z.B. 7-zip) unterstützen allerdings die Angabe der Dateigröße in einem Extrafeld mit der Signatur 0x0100, wie es auch von Personal Backup benutzt wird.

Verschlüsselte GZip-Dateien

Details dazu sind weiter unten näher beschrieben.

Erstellen von Zip-Archiven

Dateinamen

Beim Zip-Format ist in der Spezifikation Version 6.3.6 v. April 2019 beschrieben, wie mit Unicode-Dateinamen umzugehen ist: Wenn das Bit 11 des general purpose bit flag gesetzt ist, sind Dateiname und Kommentar UTF-8-kodiert. Personal Backup hält sich an diese Vorgabe. Inzwischen unterstützten auch viele Packprogramme diesen Standard (z.B. WinZip Vers. 12, WinRar Vers. 3.80 und 7-Zip Ver. 9.20) und auch der Windows-Explorer.

Verschlüsselte Zip-Archive

Details dazu sind nachfolgend näher beschrieben.

Verschlüsselung

Die Dateien werden nach dem AES-Verfahren verschlüsselt. Dabei werden die gleichen Routinen, wie bei WinZip verwendet (siehe Infos bei Winzip und bei Brian Gladman). Das erzeugte Datenformat hängt allerdings vom gewählten Backup-Modus ab:

Keine Komprimierung (proprietäres Datenformat):

Die Daten werden in gleicher Weise geschrieben, wie in eine Zip-Datei nur ohne vorangehende Komprimierung (siehe dazu auch). Zu beachten ist, dass das verwendete Format kein allgemeiner Standard ist. Die Wiederherstellung der Dateien kann daher nur mit der programminternen Funktion oder dem Dienstprogramm PbRestore durchgeführt werden.

   Signatur   : JREx  (4 Bytes - ab Vers. 5.8.5)
   TimeStamp  : Unix time (4 Byte - ab Ver. 5.9.0)
   Attribute  : Datei-Attribute (2 Byte - ab Ver. 5.9.0)
   Enc-Header : 10, 14 oder 18 Bytes (abhängig von der Verschlüsselungstiefe):
                Saltwert (8, 12 oder 16 Bytes) + Kennwortprüfwert (2 Bytes)
   Enc-Data   : Anzahl Bytes wie Quelldatei
   Enc-Trailer: 10 Bytes Authentifizierungscode

Mit Komprimierung (modifiziertes GZip-Format):

Die Daten werden zunächst nach dem Standard-GZip-Verfahren komprimiert und dann nach dem AES-Verfahren verschlüsselt. Da die verschlüsselten Daten eine eigene Verifizierung beinhalten, wird die GZip-Checksumme immer auf 0 gesetzt. Das GZip-Dateiformat ist in RFC1952 beschrieben. Zu beachten ist, dass dieser Standard keine Verschlüsselung vorsieht. Das verwendete Datenformat ist dem nur angelehnt. Die Wiederherstellung der Dateien kann daher nur mit der programminternen Funktion oder dem Dienstprogramm PbRestore durchgeführt werden.
Hinweis: Ab Vers. 5.2 haben verschlüsselte gzip-Dateien die Erweiterung gze.

   GZip-Header : 10 Bytes wie Standard
                 neu: Flag-Byte: bit 5 = encrypted
   Extrafeld   : (ID=1) Optional für Dateien > 4GB  - 20 bytes
   Extrafeld   : (ID=$524A) Signatur JR + Angabe der Verschlüsselungstiefe 
                 (ab Version 5.8.5) - 6 Bytes
   Dateiname   : ISO-8859-1 (OS=0 - FAT) oder UTF-8 (OS=11 - NTFS)
   Enc-Header  : 10, 14 oder 18 Bytes (abhängig von der Verschlüsselungstiefe)
   Enc-Data    : Anzahl Bytes wie komprimierte Quelldatei
   Enc-Trailer : 10 Bytes  (s.o.)
   GZip-Trailer: 8 Bytes
                 Crc immer = 0

Zip-Archive (weitgehend kompatibel zum Standard):

Eine Beschreibung des Zip-Formats findet man bei PkWare, Hinweise zur Verschlüsselung bei WinZip. Die von Personal Backup erstellten Zip-Archive mit Verschlüsselung der Dateiinhalte sind kompatibel zu dem in WinZip verwendeten Format und können daher mit allen Packprogrammen, die dies unterstützen, wiederhergestellt werden.
Wichtiger Hinweis: Zusätzlich bietet Personal Backup ab Vers. 5.9.4 die Möglichkeit auch die Dateinamen zu verschlüsseln. Dies ist dann allerdings nicht mehr voll kompatibel zu WinZip. Öffnet man ein solches Archiv mit einem Fremdprogramm, wie WinZip oder 7zip, wird dort keine Verzeichnisstruktur angezeigt. Alle Dateien und Verzeichnisse werden anstatt mit ihrem eigentlichen Namen mit einer laufenden Hex-Nummer gekennzeichnet. Der richtige Name ist verschlüsselt in einem Extrafeld (s.u.) des lokalen Dateiheaders abgelegt. Zum Entpacken muss die programminterne Restorefunktion oder das Zusatzprogramm PbRestore verwendet werden.

  Ergänzungen zum WinZip-Format:
    Local File Header / Central Directory Header:
       general purpose bit flag - Bit 8:	filenames are encrypted
       
    Extra Data Field for encrypted filenames
    ----------------------------------------
    Offset  Size  Contents  
    0       2     Header ID of extra field (0x9909)  
    2       2     Data size (n) in bytes (variable)
    4       n     Encrypted filename     
   

Länge von Dateipfaden

Für Pfadlängen gibt es unter allen Windows Betriebssystemen an vielen Stellen immer noch eine Beschränkung auf 260 Zeichen (Weitere Infos). Dies betrifft alle Anwendungen, die nicht die Unicode-Versionen der Windows-API-Funktionen verwenden, und unter Windows XP auch alle Anwendungen, die die Windows-Shellkomponenten benutzen, wie z.B. der Explorer. Diese Beschränkung ist erst seit Windows 7 aufgehoben.
In Personal Backup macht sich dies an allen Stellen bemerkbar, wo das Programm Windows-Shell-Komponenten verwendet (z.B. im Dialog zur Auswahl eines Verzeichnisses oder einer Datei). Erst ab Windows 7 sind auch hier lange Pfade erlaubt.
Intern wird für alle Datei-verarbeitenden Windows-Funktionen (z.B. beim Kopieren) das Pfad-Präfix "\\?\" verwendet, wodurch eine max. Länge von ca. 32000 Zeichen möglich ist. Daher ist seit Personal Backup Version 5 die Sicherung, das Überprüfen, das Wiederherstellen und das Löschen von Dateien mit überlangen Pfaden möglich, auch wenn dies noch nicht von allen anderen Programmen vollständig unterstützt wird (z.B. Windows-XP-Explorer). Ein mir bekannter Dateimanager, der mit langen Pfaden keine Probleme hat, ist der TotalCommander (seit Version 7.5).

Wichtiger Hinweis: Auch unter Windows 10 und 11 gibt es immer noch ein Problem, wenn lange Dateipfade (>260 Zeichen) in Zip-Archiven verwendet werden. Der Windows-Explorer meldet dann, dass es sich um einen ungültigen Zip-komprimierten Ordner handeln würde.

Backups beim Abmelden/Herunterfahren

Leider wird dies vom Windows-System nicht wirklich unterstützt. Die Voreinstellungen von Windows sind so, dass das Herunterfahren möglichst schnell geht. Dem widerspricht es natürlich, wenn zu diesem Zeitpunkt noch eine u.U. auch länger dauernde Datensicherung durchgeführt werden soll.
Es gibt aber eine Möglichkeit, das System an dieser Stelle zu überlisten. Personal Backup fängt dazu die Windows-Nachricht WM_QUERYENDSESSION, die nach dem Einleiten des Abmelde-Prozesses an alle laufenden Anwendungen gesendet wird, ab und unterbricht den Vorgang. Nachdem das Backup ausgeführt wurde, wird dann das Abmelden oder Herunterfahren über eine der API-Funktionen ExitWindowsEx oder InitiateSystemShutdownEx wieder neu eingeleitet.
Damit das funktioniert müssen allerdings folgende Bedingungen erfüllt sein:

1. Der Registry-Schlüssel HKEY_CURRENT_USER\Control Panel\Desktop\AutoEndTasks muss auf "0" gesetzt sein (weitere Infos bei Microsoft).
2. Weder das System noch irgendeine andere Anwendung dürfen das Herunterfahren erzwingen, indem sie die Rückmeldung auf die o.g. Systemnachricht, das System noch nicht herunterzufahren, einfach ignorieren. Darauf hat man von Seiten des Programms dann keinen Einfluss mehr.

Möglicherweise spielen auch noch die folgenden Registry-Einstellungen eine Rolle:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
  WaitToKillServiceTimeout = <time> ⇒ Wartezeit in ms
• HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System
  AllowBlockingAppsAtShutdown = 1 ⇒ keine autom. Beendigung von Anwendungen, = 0 ⇒ Anwendungen werden automatisch beendet (siehe dazu auch die Gruppenrichtlinie Administrative Vorlagen ⇒ System ⇒ Optionen für das Herunterfahren)