Lupinhos Home

Also: HardlinkBackup löscht nichts auf den Quellordnern! - Es sei denn, Du stellst ein Backup wieder her und markierst explizit, dass gelöscht werden soll.
Ich finde den Titel des Themas schon sehr reißerisch. HardlinkBackup wird bei tausenden Benutzern eingesetzt und bis höre ich zum ersten mal von so etwas.
Hast Du irgendwelche Logfiles, Screenshots oder ähnliches, anhand dessen man nachvollziehen kann, was passiert ist?

Reißerisch wollte ich nicht sein - aber prägnant sollte es schon sein.
Immerhin ist es eine recht unangenehme Erfahrung, wenn ein Programm plötzlich anfängt die Festplatte zu löschen.

Ich habe leider als Backupziel E: angegeben, die Backup-Ordner wurden dann auch immer direkt unter E: angelegt (wie gesagt, mit nur zwei Dateien drinnen). Ich vermute, dass deshalb auch alles auf E: zum Löschziel wurde.
Ein Logfile habe ich leider nicht, das liegt ja bei den kopierten Daten und wurde mitgelöscht.
Das einzige, das ich beisteuern kann, ist die hbd-Datei, die im Quell-Ordner liegt. Allerdings ist die offensichtlich seit meine ersten Versuchen unverändert. Ich habe auch einen Screenshot gemacht, wie sich das Programm jetzt präsentiert.

Meine Vermutung ist eher, dass es etwas mit meinen Markierungen zum Backupsatz-Löschen zu tun hat. Vielleicht eben auch damit, dass ich die betreffenden Ordner möglicherweise schon vorher gelöscht habe.

Noch etwas:
Ich wollte eigentlich auch die Meldung transportieren, dass das erwähnte Problem mit den mangelnden Zugriffrechten mit den beiden erwähnten Optionen zu tun haben könnte. Komischerweise aber aktiviert.
Immerhin haben dieses Problem ja auch andere schon gemeldet.

Wie versendet man denn eine hbd-Datei?
Ich habe erst jetzt gesehen, dass die drei "Durchsuchen..."-Schaltflächen nur für Bilder sind.

Das mit den gleichen Quellverzeichnissen täuscht, da der Pfad abgeschnitten ist. In der hbd-Datei sieht man das.
Hardlinkbackup fragt beim Beenden, ob die Änderungen gesichert werden sollen. Ich das Programm aber abgebrochen, als ich die Löscherei bemerkt habe. Daher gibt es keine Lösch-/Aufräumoptionen zu sehen.

zu meinem Backup-Versuch:
Ich habe ja das Problem mit den mangelnden Zugriffsrechten (zumindest meldet Hardlinkbackup das). Um das zu verifizieren habe ich die Backup-Richtung umgekehrt und vom Backup-Laufwerk auf das Arbeitslaufwerk versucht zu sichern. Und der Einfachheit halber habe ich auch kein eigenes Verzeichnis angelegt sondern den Test gleich ins Wurzelverzeichnis gemacht. Das ist mir jetzt zum Verhängnis geworden, als eben vom Wurzelverzeichnis ausgehend alles ins Lösch-Visier gekommen ist.

Mein Ärger rührt sicherlich auch daher, dass dieses Zugriffsrechteproblem schon von zumindest zwei Usern thematisiert wurde (beispielsweise am 8.3. und 18.4.) und weiter ein völliges Rätsel sein dürfte.

Hallo,

die hbd-Datei habe ich schon zweimal versucht hochzuladen, anscheinend kann man aber nur Bilder hochladen.
Ich habe jetzt von der hbd-Datei einen Screenshot gemacht und lade den hoch.

Wie schon geschrieben: Die beiden im Screenshot sichtbaren Quellverzeichnisse zeigen zwei abgeschnittenen Pfade, die sich erst hinten unterscheiden.

Um hier keine Verwirrung entstehen zu lassen versuche ich nochmals den Hergang zu beschreiben:
1. Ich verwende derzeit qtdsync, das ganz gut funktioniert, aber am Ende oft Fehler meldet, die dann nicht auffindbar sind.
2. Daher habe ich hardlinkbackup probiert und ein Testbackup auf mein Sicherungslaufwerk versucht (Quelle auf E:, Ziel auf I:).
3. Das funktionierte allerdings nie. Als Fehler wurden mangelnde Zugriffsrechte gemeldet. Das das nicht stimmen kann, zeigte schon die Tatsache, dass das Programm immerhin in der Lage war, den Ordner mit der Logdatei und einer hbs-Datei anzulegen.
4. Mangelnde Zugriffsrechte wurden übrigens unabhängig von den Userberechtigungen (also auch als admin) gemeldet.
5. Testhalber habe ich dann die Sicherungsrichtung umgekehrt. Auf meinem Arbeitsverzeichnis sollte es keine Zugriffsrechteprobleme geben. Der Einfachheit halber habe ich kein eigenes Sicherungsverzeichnis erstellt, sondern direkt ins Wurzelverzeichnis sichern lassen.
6. Das hat mit dem gleichen Ergebnis wie der ursprüngliche Versuch funktioniert (ein Ordner mit zwei Dateien und der gleichen Fehlermeldung).
7. Nachdem sich wegen meiner Versuche schon eine Menge Backupsätze angesammelt haben (alle fehlerhaft), habe ich die auf der hardlinkbackup-Oberfläche zum Löschen markiert. Dass sie erst nach einem Sicherungslauf gelöscht werden wusste ich nicht, daher blieben sie vorerst nur markiert.
8. Dann habe ich angefangen, die Optionen zu variieren (Link Skript, vielleicht auch Move und Mirror), mit immer dem gleichen Ergebnis.
9. Dann habe ich wieder im hardlinkbackup-Forum bzw. den Kommentaren auf der Homepage gesucht und den Hinweis auf die beiden Häkchen für Metadaten und Dateiberechtigungen gefunden und einfach einmal aktiviert (obwohl der Hinweis eigentlich Deaktivieren lautet). Die anderen Optionen waren meiner Erinnerung nach aber wieder auf Standardeinstellung (da ich zwischendurch das Programm immer wieder neugestartet und nie gespeichert habe).
10. Und dann lief die Sicherung plötzlich - und bereinigte dann auch gleich das halbe Laufwerk E:, bis ich es endlich abbrechen konnte!

Jetzt habe ich noch ein Logfile in ..\AppData\Local\.. gefunden, das zum fatalen Lauf gehört. Das dürfte für Lupinho wohl am interessantesten sein.

Die zwei Bilder zeigen:
1. Die hbd-Datei der Sicherung, die zum Löschen führte. Wie bereits gesagt: Das Dateidatum ist seit den ersten Versuchen unverändert, die geänderten Optionen wurden nie abgespeichert.
2. Das Logfile aus ..\AppData\Local\..

Ich will die Textdateien nicht einfach als Text reinkopieren, da sonst die Nachricht überquillt. Falls Bedarf danach besteht, kann ich das aber nachholen.

Probieren will ich vorerst nichts mehr, da das ganze doch recht zeitaufwendig ist.
Ich denke, ich habe recht ausführlich beschrieben, was ich getan habe, bevor das Programm meine Daten zu Löschen begann.
Betonen möchte ich: Es ist mir nicht daran gelegen, das Programm schlecht zu machen, allerdings sollte anderen Usern diese Erfahrung nach Möglichkeit erspart bleiben.

Vielleicht klärt sich in diesem Zusammenhang ja auch mein ursprüngliches Problem mit den Zugriffsrechten.

Liefern könnte ich noch einen Screenshot der ursprünglich probierten Sicherungen (von E: auf I:) und ein Logfile eines solchen Laufes. Dort wären die Zugriffsrechte-Fehlermeldungen ersichtlich.

Danke für Deine Versuche, das nachzustellen.

Zitat von Mr. Magpie am August 13, 2013, 19:14
Sei mir nicht böse, aber wenn der Benutzer Otto123 wirklich existiert, alle Rechte im Zielllaufwerk reso. Zielverzeichnis hat und dieses natürlich NTFS-formatiert ist, dann sollte das auch klappen. (o:

Ich würde schon sehr an der Software zweifeln, wenn man meine Erfahrung unter Obskuritäten einreiht.
Warum auch immer, hat es in meinem Fall zu dem beschriebenen Ergebnis geführt!

Der Benutzer Otto123 existiert, die Rechte im Ziellaufwerk sind ok (zumindest fürs Löschen haben sie gereicht) - und auch die Laufwerke sind normal formatierte NTFS-Laufwerke.
Laufwerk E: und I: liegen auf unterschiedlichen Festplatten, die beide fix im PC eingebaut sind. Laufwerk E: liegt auf einer 500 GB großen Seagate-Platte (angeblich 16 MB Cache), Laufwerk I: ist das einzige auf einer 1500 GB großen Samsung-Platte (angeblich 32 MB Cache).
Beide wurden unter Vista erstellt und laufen jetzt meist unter Windows 8 (beide 64-bit). Hardlinkbackup habe ich unter Windows 8 installiert.
Auf dem PC gibt es ein Dual-Boot-System (die Laufwerke C: und D:).

Ich könnte mir vorstellen, dass Lupinho mehr aus dem Logfile lesen kann und dass das zumindest klärt, warum es zur großen Löschaktion kam.

Freuen würde mich natürlich auch, wenn sich das Rechteproblem irgendwie klären liese. Aber anscheinend haben das nicht allzu viele User.