Vor ein paar Wochen habe ich vorsichtig ein altes Backup von meinem Datenlaufwerk gelöscht. Ich habe eine Duplikatsprüfung zwischen dem alten Backup und der Live-Kopie durchgeführt und die alten Kopien in den Papierkorb gelöscht. Es lief einwandfrei und wie erwartet, bis ich plötzlich nichts mehr löschen konnte. Immer wenn ich versuchte, eine Datei zu löschen –beliebigDatei – aus der alten Sicherung, würde es fehlschlagen.
Ich untersuchte den Papierkorb und mir kam der Gedanke, dass es vielleicht daran liegen könnte, dass dort einfachzu viele Dateienin den Mülleimer. Ich rede nicht vonGröße, aber dieNummervon Dateien. Hier sind einige Fakten zur Situation:
- Es ist ein Windows XP-System
- Das Volume mit dem alten Backup ist FAT32
- Das Volume mit dem alten Backup hatte 302 MB freien Speicherplatz
- Das Problem trat auf, sobald sich 31.594 Dateien im Bin befanden
- Die wiederverwendeten Dateien verbrauchten 236 MB
- Die
INFO2Datei (die die ursprünglichen Dateinamen der recycelten Datei enthält) ist über 24 MB groß - Der Versuch, auch nur eine weitere Datei zu löschen, würde nicht funktionierenunabhängig von seiner Größe
- Der Papierkorb ist so konfiguriert, dass er auf allen Laufwerken keine Beschränkungen hat
Ich habe versucht, das nachzuschlagen, aber dieDas nächste, das ich finden kannist Information über Grenzen derGrößedes Papierkorbs, nichts über dieAnzahl der Dateien.
Hat jemand davon gehört? Kann jemand bestätigen, dass es eine Grenze gibt fürwie vieleDateien können gespeichert werden?
Antwort1
Ein FAT32-Verzeichnis kann 65.536 Verzeichniseinträge haben.
Jede Datei und jedes Unterverzeichnis benötigt, abhängig von der Länge seines Namens, zwei bis dreizehn Einträge.
Im optimistischsten Fall könnte Ihr Papierkorb also 65.536 /2 = 32.768 Dateien+Verzeichnisse enthalten, wenn alle Dateinamen im Bereich 8,3 liegen. (Kurznamen)
Ihre 31594 Dateien + 53 Verzeichnisse scheinen das Limit zu erreichen.
Es gibt wahrscheinlich einige Dateien, die aufgrund längerer Dateinamen >2 Einträge benötigen.
Bearbeiten:
Die FAT32-Spezifikation ist hier verfügbar:
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx
Es enthält Einzelheiten zu allem, einschließlich der Verzeichnisstruktur und der Art und Weise, wie lange Dateinamen (LFNs) in Verzeichnissen gespeichert werden. Grundsätzlich gibt es einen Verzeichniseintrag, der immer die kurze (8.3) Version des Dateinamens enthält. Und da Windows bei langen Dateinamen (LFNs) die Groß- und Kleinschreibung berücksichtigen muss, wird für die LFNs ein separater Verzeichniseintrag benötigt (oder mehrere, wenn sie länger als 13 Zeichen sind).
Um die Ziele der Zugriffslokalität und Transparenz zu erreichen, wird der lange Verzeichniseintrag als kurzer Verzeichniseintrag mit einem speziellen Attribut definiert.
Bearbeitung Nr. 2:
Ich habe einige Tests in einer VM mit Windows XP und einem FAT32-Laufwerk (mit dem Papierkorb auf Maximum) durchgeführt.
In einem dataVerzeichnis habe ich ein Unterverzeichnis erstellt, testnach dem ich diese Batchdatei ausführe:
@echo off
if "%1"=="####" goto %1
for %%a in (0 1 2 3 4 5 6 7 8 9 A B C D E F) do call %0 #%1 %2 %3 %4 %%a
goto EOF
:####
echo %2%3%4%5
echo test > test\%2%3%4%5
:EOF
Das Ergebnis sind 65534 Dateien (nur mit Kurznamen). Wie erwartet konnten die letzten beiden Dateien ( FFFEund FFFF) aufgrund der 2 Verzeichniseinträge ( .und ..) nicht hinzugefügt werden. Daher .werden ..nur 2 Einträge benötigt, was für später gut zu wissen ist)
Als nächstes habe ich über 45.000 Dateien ausgewählt und diese im Explorer gelöscht
(das Sammeln der Informationen vor dem Löschen hat eine Weile gedauert :)
Da die Dateinamen im Papierkorb De1, De2usw. lauten, handelt es sich hier um lange Dateinamen (aufgrund der Groß- und Kleinschreibung). Der Explorer hat nach dem Löschen von 32765 Dateien einen Fehler ausgegeben.
Das dir /a/xgab mir 32767 Dateien und 2 Verzeichnisse.
32765 Benutzerdateien (mitLFN), ein INFO2und desktop.ini(beide ohne LFN).
(32765 * 2) = 65530 + 2 (ohne LFN) + 2 Verzeichniseinträge = 65534
Mmmm, noch 2 zu wenig ;)
Mit 65534 sollte es möglich sein, 1 (mit LFN) mehr hinzuzufügen. Ich denke also, dass Windows möglicherweise einen zusätzlichen freien Eintrag für eine temporäre Datei benötigt.
Aber wie Sie sehen könnenDas Limit liegt bei 65530 Verzeichniseinträgendavon belegt jede Datei 2.
(So32765 Dateienweil die resultierenden Dateinamen Groß- und Kleinschreibung aufweisenund noch wenigerwenn die Erweiterung größer ist als 3).
Als ich das getestet habe, waren die Dateinamen alle De1, De2usw. (die Originale waren alle Dateien ohne Erweiterung). Ihre Dateinamen haben Erweiterungen. Wenn sie längere Erweiterungen (>3) haben, könnten mehr Einträge erforderlich sein, da Windows die Erweiterung im Papierkorb speichert.
Es ist jedoch in der Tat merkwürdig, dass Microsoft sich nicht für ausschließlich Kurznamen im Papierkorb entschieden hat, da die (ursprünglichen) Dateinamen in gespeichert werden sollten INFO2.
Bearbeitung Nr. 3:
Ich habe gerade bestätigt, dass der Löschmechanismus von Windowsbrauchtein zusätzlicher Verzeichniseintrag.
Ich habe es xcopy e:\recycled\*.* e:\test\ /e/s/hmit einem vollen Papierkorb gemacht und alle Dateien (32767 Dateien) aus dem Papierkorb in ein Testverzeichnis kopiert.
Ich konnte noch 1 Datei De_test1.txt(LFN) in erstellen e:\test. Beim Erstellen De_test2.txttrat ein Fehler auf.
Daher sollte „Windows löschen“ ausreichen, um eine weitere (LFN-)Datei zu erstellen, aber aus einem internen Grund ist dies nicht möglich.
So fürnormale OrdnerDie Grenze liegt bei 65536 -2 für .und ..= 65534 Einträge.
und für diePapierkorbes ist 65536 -2 für .und ..und -2 für desktop.iniundINFO2
Und-2 für eine temp.file (?) = 65530 Einträge
und mit 65530 Einträgen sind es maximal 32765 Dateien (undwenigerwenn Erweiterungen >3 sind).