Um Daten einer Datei physikalisch zu löschen, reicht es aus, sie einmal zu überschreiben. Mit was, ist egal. Wenn das Speichermedium nicht defekt ist, braucht man keine komplizierten Algorithmen, um wirre Muster zu erzeugen, mit denen eine Datei überschrieben wird. Einmal überschreiben reicht, reichte es nicht, ist das Medium wahrscheinlich defekt und es klappt auch mit komplizierten Mustern nicht.
Nachfolgend wird die fiktive Datei kompromittierend.jpg mit Null überschrieben:
cat /dev/null > kompromittierend.jpg
Danach kann die Datei einfach gelöscht werden.
Nachtrag
Überschreiben von mehreren Dateien in einem Verzeichnis:
1
2
3
4
for file in *
do
cat /dev/null>$file
done
Skrip speichern als „killpix.sh“ und starten mit: bash killpix.sh
Achtung! Das Programm löscht auch rigoros sich selbst. Eine verbesserte Version verhindert dies:
1
2
3
4
5
6
7
for file in *
do
if [ "$file" != "killpix.sh" ]; then
cat /dev/null>$file
rm $file
fi
done
Wer lieber kontrollieren möchte, ob die jeweilige Datei wirklich mit NULL überschrieben wurde, kann die Zeile rm $file auch weg lassen oder auskommentieren.
Die Routine hatte mit *.jpg einige Dateien ausgelassen, die solche Dateinamen hatten: 10(10).jpg – keine Ahnung, warum dieses Problem auftritt. Ich habe mich damit beholfen, diese Dateien von Hand umzubenennen; etwas in aaa.jpg und b.jpg. Danach hat es wie oben funkioniert.
Der Witz ist, dass man keine teuren Softwarelösungen zum sicheren Löschen benötigt.
Hier die Ergebnisse für ein Jpeg-File vor und nach dem Nullen:
Jpeg-Bild mit normalem InhaltJpeg-Bild nach dem Nullen
Kurz vor 21 Uhr stellte ich fest, dass ich kaum noch Bier im Hause habe. Der Rewe, der oft sehr preiswert Bier in Kisten anbietet, hat bis 22 Uhr geöffnet und wurde zum Bier-Dealer der Wahl erkoren.
Samstag Abend bei bestem Sonnenwetter und Feiertag am Montag zeigen sich Supermärkte von ihrer knallhart marktwirtschaftlichen Seite. Kisten von Allerweltsbieren wie Veltins oder Beck’s kosten nun anstatt um und bei 10 €: stolze 19,99 €. Festtagsaufschlag. Paulaner dunkles Weizen war für 13,99 € zu haben, aber das waren halbe Liter. Ich vertrage Bier besser, wenn ich 0,33 l-Flaschen nehme.
In der letzten Not kaufte ich schlussendlich „Nordlicht“, 20 × 0,33 l für 7,77 € engegen meiner Gepflogenheit, erstmal 2 Flaschen zum Probieren zu kaufen. Nordlicht scheint so eine Art Oettinger Bier der REWE Markt GmbH Nord zu sein. Naturtrübes Bier ist mir eh sympathischer als solches, dass durch Filtern mit Kieselgur geklärt wurde. Geschackserlebnis … erstmal nicht so aufregend, aber gekühlt schmeckt das Bier erträglich. Ich muss es nicht wegschütten, aber nochmal kaufen werde ich es auch nicht. Dann würde ich doch lieber Öttinger-Pils versuchen, aber das gibt es auch nur in 0,5 l-Flaschen. Also rechtzeitig „Beck’s Unfiltered“ kaufen.
Pi mit der Trägerplatine des NVMe-SSD-Speichers zu verbinden, ist Feinarbeit sonder gleichen. Ohne Fein-Pinzette mit gebogener Spitze hätte ich das vermutlich kaum geschafft. Ebenso war mein Binokular-Mikroskop ein wichtiges Hilfmittel, um den richtigen Sitz der Verbindung zu überprüfen.
259 GB NVMe wird erkannt als: nvme0n1
Die SSD-Disk wird sauber erkannt. Harwareverbindung ist also OK. Das Mounten dieses Laufwerks muss noch folgen.
Sandwich-Aufbau mit SSD-Platine ist sehr beengt
Die wenigen Löcher in der Trägerplatine des NVMe-Speichers werden nach Einsetzen des SSD-Speichers teilweise verdeckt. Wahrscheinlich reichen die dann nur noch randlich vorhandenen Löcher nicht aus, das Gesamtsystem ausreichend zu kühlen. Es wird bereits im Leerlauf ziemlich heiß. Ich werden noch einen Kühlkörper mit Lüfter dazwischen setzen müssen.
BTW: Es gibt auch NVMe-Platinen, die unter die Haupplatine montiert werden. Ob das thermisch besser ist, kann ich nicht beurteilen.
System auf SSD kopieren
Auf meinem raspi 5 habe ich Debian GNU/Linux 12 (bookworm) installiert. Da darauf kein git vorhanden war, musste ich es erst installieren:
sudo apt-get install git
Danach musste rpi-clone installiert und damit dann das System übertragen werden:
Bei der Durchsicht des Fehlerprotokolls unter Windows (siehe auch Artikel Ereignis-Protokoll unter Windows 11 aufrufen) fällt das massenhafte Auftreten des Fehlers Metadata Staging-Fehler 0×80070490 auf.
Anscheinend handelt es sich hier nicht um einen Fehler in der Windows-Installation. Im Blog von Günter BornWindows meldet „Metadata Staging“-Error (0×80070490) im DeviceSetupManager (Dez. 2023) findet man zu dieser Fehlermeldung näheres.
Günter Born schreibt, das Problem aufträte auf, seit Ende November 2023 ein MetaData-Server von Microsoft nicht mehr erreichbar sei und nennt in einem weiteren verlinkten Artikel ein Workaround: In der Registry (regedit) findet sich der Schlüssel DeviceMetadata (mit Strg-F nach „DeviceMetadata“ suchen).
Hier soll der dort eingetragene URL durch „.“ ersetzt werden; in guter fachlicher Praxis bitte vorher den Schlüssel exportieren.
Ruft man diesen URL im Webbrowser auf, wird folgendes angezeigt: „Service Unavailable. Please try again later.“.
Allein schon aus Gründen der Übersichtlichkeit des Fehlerprotokolls, sollte man diese Änderung vornehmen, da hier hunderte von Fehlern binnen weniger Tage auftreten, erschwert dies wirkliche Fehler festzustellen. – Bei mir wird dieser Fehler bis zu 20 mal pro Sekunde (!) protokolliert!
Seit ich das Workaround hat bei mir keine grundlegende Verbesserung gebracht. Erst sah es so aus, als sei damit Schluss, aber nach dem nächsten Systemstart tritt der Fehler wieder auf. Ich habe den Eintrag nun ganz gelöscht.
Auf Answers.microsoft.com wird gesagt, dass folgender URL gesetzt werden soll: http://dmd.metaservices.microsoft.com/dms/metadata.svc. Ruft man diesen URL im Browser auf, gibt es allerdings eine Fehlermeldung „Bad Gateway“.
Also weitere beobachten. Man müsste den Service am besten ganz abschalten; Preisfrage: Wie macht man das?
Komisch, als sei dieses wichtige Werkzeug der Fehlersuche eine Geheimwissenschaft, begegnet dem Nutzer diesem Programm so gut wie nie. Man muss aktiv danach suchen, aber auf der deutschsprachigen Seite von Microsoft wird ist der entscheidende Part der Erläuterung, nämlich „Wie überprüfe ich Fehlerprotokolle in Windows 11?“ derart kryptisch (siehe Beitragsbild), dass man damit nichts anfangen kann.
Üblicherweise sucht man dann im Web, aber meistens liest man dort Sätze wie: „Öffnen Sie die Ereignisanzeige über das Startmenü.“ (diskpart.com) und ähnliches, was ebenfalls nicht hilfreich ist.
Hier kurz als Memo, wie man das Ereignisproptokoll tasächlich öffnet:
Erste Möglichkeit
In der Shell (=Konsole):
C:\Users\Blah>eventvwr
Also entweder direkt mit Windows+R oder in der Shell der persönlichen Präferenz – bei mir meist: powershell. Aber das ist nicht wirklich entscheidend. Ich mache das nur so, weil bein nächsten Aufruf im Ausführungsdialog von Windows+R „powershell“ steht, weil ich ja nicht nur mit dem Ereignisprotokoll arbeite. Das spart geringfügig Tipparbeit. ;-)
Zweite Möglichkeit
Eingabe von Windows+X, dann öffnet sich eine Auswahlliste, in welcher man „Ereignisanzeige“ auswählt, das dann sofort gestartet wird.