Ein Nutzer hat sich gerade mit einer merkwürdigen Beobachtung an mich gewandt. Beim Versuch, Dateien zu kopieren, meldet sein Windows 10 Version 2004, dass nicht genügend freier Speicherplatz auf der Quell-Laufwerk vorhanden sei und bricht den Vorgang ab. Hier einige Infos zu der 'exotischen' Konstellation.
Anzeige
Das Ganze ist eine Konstellation mit einem Veracrypt-Volumen, was eine Ursache sein kann. Da ich nichts wirkliches dazu im Netz gefunden habe, stelle ich den Fall mal hier im Blog ein. Vielleicht gibt es noch Betroffene oder es ist eine Ursache bekannt.
Die Problembeschreibung
Blog-Leser Sebastian F. hat mich über Xing wegen des Problems, dass Windows das Kopieren von Daten verweigert, kontaktiert. Er schreibt:
ich bin gerade genervt da ich noch sehr viele TB an Daten reorganisieren muss und Windows mir den Dienst verweigert. Meine Google-Suchen verlaufen ergebnislos. Entweder benutze ich die falschen Suchbegriffe oder ich bin auf einen neuen Fehler gestoßen – und da sind sie mir eingefallen!
Seine Umgebung ist ein Rechner mit Windows 10 Mai 2020 Update (Version 2004, Build 10.0.19041), auf dem er Daten in einem mit Veracrypt verschlüsselten Laufwerk abgelegt hat. Nun versucht er Dateien von diesem Laufwerk auf ein anderes Laufwerk zu kopieren. Er schreibt dazu:
Beim Kopieren VOM(!) Veracrypt-Laufwerk (Verschlüsselter Container als Laufwerk eingebunden – 20 GB, 5 GB frei) eines Ordners (7GB) AUF(!) die lokale Festplatte (1TB, 460 GB frei) bringt Windows folgende absurde Fehlermeldung:
Auf DATA ist nicht genügend Speicherplatz vorhanden. Weitere 2,13 GB sind erforderlich, um diese Dateien kopieren zu können.
Sebastian schreibt dazu, dass er nicht Quelle und Ziel verwechselt habe und fragt, ob der Fehler bekannt sei. Da mir noch nichts dergleichen unter die Augen gekommen ist, stelle ich es hier im Blog ein.
Anzeige
Mögliche Ursachen, die mir einfallen
Wenn als Ziel ein FAT 32-Laufwerk verwendet würde, können die 4 GB-Grenze für Dateien ein Problem sein, wie in diesem Artikel skizziert wird. Dürfte in obigem Szenario aber nicht zutreffen. Meine erste Vermutung wäre, dass die Veracrypt-Filesystem-Treiber zum Zugriff auf die Container da möglicherweise einen Fehler enthalten. Oder der betreffende Prozess versucht auf dem Quell-Laufwerk Dateien zwischen zu speichern, bevor sie auf das Ziellaufwerk kopiert werden.
Mir fiele auch noch ein, dass das Verzeichnis TEMP auf dem Windows-Laufwerk zur Zwischenspeicherung verwendet wird und der freie Speicher auf der Systempartition nicht zum Kopieren ausreicht. Ich habe noch einen vergleichbaren Fall zu Dropbox gefunden. Dort ist Dropbox die Ursache und der Betroffene hat sich mit einem Trick (der im Thread beschrieben ist) beholfen. Trifft aber den oben beschriebenen Fall nicht ganz.
Ist irgend jemandem von Euch dieses Szenarios schon mal untergekommen? Ist das bekannt und gibt es Lösungen?
Anzeige
Danke für die schnelle Reaktion!
Ergänzungen:
Es gibt 2 fest verbaute Festplatten auf dem Rechner, wobei auf der einen eine Standardinstallation von Windows läuft. Auf der Windows-Partition sind noch 44GB frei.
Auf der zweiten Festplatte (1 Partition) liegt der Zielordner.
Alle Partitionen (auch VeraCrypt) auf dem Rechner sind NTFS-Partitionen.
dateien auf festplatten belegen immer ein vielfaches der clustergroesse. koennte es sein, dass es sich bei den zu kopierenden daten um berge von kleinstdateien handelt? falls die beim kopieren den umweg ueber das temp-verzeichnis nehmen sollten (anm.: ich nutze veracrypt nicht), koennten sie vielleicht den geringen freiraum auf der windows-partition ueberfordern.
Wie und wo wird denn der zu kopierende Ordner entschlüsselt bevor er kopiert wird?
Bei einer Ordnergröße von 7 GB und 5 GB freiem Platz fehlen dann halt 2(,13) GB
Das Entschlüsseln sollte der VeraCrypt-Treiber machen.
Ist "eigentlich" völlig transparent für den User.
Es geht ja um ein "Laufwerk", nicht um einen "Container".
Aber auch den "Mountet" man.
Microsoft hat viel von Unix übernommen.
Den beschriebenen Fehler kann ich jetzt zwar nicht nachvollziehen, das Problem lässt sich aber bestimmt mit Robocopy umschiffen.
robocopy /mir /w:1 /r:1 Quellpfad Zielpfad
Das erzeugt am Zielpfad eine 1:1 Kopie. Falls im Zielpfad noch andere Datein existieren, so werden die gelöscht. Falls man das nicht will, dann /mir durch /e /s ersetzen.
(Die Pfade bitte ohne abschließende Backslashes!)
Womit wird kopiert? Xplorer,xcopy,robocpy,…?
Bei robocoy mit unbuffert IO?
Ich weiß ja nicht ob MS die Nomenklatur so genau einhält,
aber "Speicherplatz" kann auch RAM-Speicher bedeuten,
und wenn der Virenscanner sich das Teil erstmal im RAM ansehen will?
Wo kommt das DATA her?
Evtl. mal auf englisch stellen, vielleicht sagt das Englische mehr.
Der obbligatorische Blick ins Eventlog (und chkdsk :-) wurde sicher gemacht.
Okay bei mir gehts ohne Probleme mit dem Explorer (2004 19041).
Das Volumen in VeraCrypt hat jedoch bei mir exFAT, Ziellaufwerk hat noch > 100GB frei und ist NTFS.
Mal eben schnell ein neues Volumen erstellt mit NTFS, der Kopiervorgang von einem Ordner (~8GB) ging ohne Probleme.
Einen hab ich noch:
Die 7GB sind wieviele Files und Verzeichnisse?
3950 Dateien, 533 Ordner
DATA ist die Windows-Laufwerksbezeichnung
VeraCrypt hab ich gerade aktualisiert – der Fehler bleibt.
Beim Kopieren von Ordnern auf einem anderen VeraCrypt-Laufwerk (29783 Dateien, 2683 Ordner) mit 13GB Daten und 6GB freiem Speicher funktioniert es.
Kopiert wird mit dem Windows Explorer.
Arbeitsspeicher sind 6 von 16 GB verfügbar.
Mit Robocopy funktioniert der Kopiervorgang.
Bei solchen Mengen dreht Windows schon mal durch oder schmiert ab.
Immer nur so 500-700MB kopieren (wenn viele Dateien, bei einzelnen gehen auch mehrere GB) mit Windows dann ist meistens OK.
VC ist aktuell? 1.24 Update 7?
Bei einer älteren Version hatte ich mal ein ähnliches Problem, mit einem statischen Container. Die genau Version, die da Probleme machte weiß ich aber nicht mehr.
Also tritt der Effekt nur in diesem einem 7GB Verzeichnis auf,
und nur, wenn mittels Explorer kopiert wird.
Andere, sogar grössere Datenmengen machen kein Problem.
Im Eventlog und beim chkdsk gab es keine Hinweise auf Problem.
Böse Files nach der Methode 42.zip liegen nicht vor.
Die Quelle ist nicht komprimiert.
Könnte es sein, das in der Quelle Hardlinks sind, die das Datenkopiervolumen aufblähen, weil das Kopierprogramm das nicht merkt und dann stump 10mal dieselben Daten kopiert, weil es 10 Referenzen daraufgibt?
Kann man evtl. was im Taskmanager-Resource Monitor sehen?
Ich denke auch , dass es der Fehler ist!
Wenn ich das zu Kopierende aufteile zu kopieren, funktioniert das kopieren!
Und nun, wie ist es ausgegangen?
Auf robocopy umgestiegen und gut ist? :-)
Allen nochmal vielen Dank für die Ideen!
Ich habe auch noch eine Fehlerprüfung über die Partition und eine Datenträgerprüfung drüber laufen lassen. Allerdings ohne weitere Erkenntnisse.
Da es sich anscheinend nur um einen spezifischen Einzelfall handelt, habe ich die Daten in kleineren Häppchen in einen neuen (größeren) VeraCrypt-Container kopiert (Windows Explorer). Das hat funktioniert, solange die kopierte Datenmenge kleiner war als der freie Speicherplatz. Leider konnte ich zur Ursache keine weiteren Erkenntnisse gewinnen.
Robocopy ist in jedem Fall eine Behelfslösung, die ich beim nächsten Mal nutzen werde, da sie wesentlich schneller ist, als alles Stück für Stück zu kopieren.
Die Antwort hat aber wenig mit meiner Fragestellung zu tun … klar macht das der VeraCrypt-Treiber … aber macht er das Block für Block, Datei für Datei oder wird erst mal das gesamte Verzeichnis entschlüsselt? Und wo wird dann das Entschlüsselte abgelegt? Wenn das, so wie ich vermute, versteckt auf dem "Laufwerk" passiert, dann ist der verbleibende Platz halt zu klein.
Wo die Entschlüsselung stattfindet bzw. zwischengespeicher wird übersteigt mein technisches Wissen zu VeraCrypt (ich vermute im Hauptspeicher), allerdings bezweifle ich, dass der gesamte Inhalt auf dem VeraCrypt-Laufwerk entschlüsselt wird/werden kann, zumal das bedeuten würde, dass aus einem verschlüsselten Container Daten ausgelesen werden, die zum entschlüsseln wieder in den verschlüsselten Container geschrieben werden (Henne-Ei-Problem). Auch die oben beschriebenen Versuche geben keinen Hinweis auf eine derartige Verhaltensweise. Wenn die alle Daten auf dem Laufwerk des Betriebssystems entschlüsselt würden, dann wäre dort ausreichend Speicherplatz vorhanden – es wird aber der Speicherplatz des Quelllaufwerks angemahnt.