herbert-m
Goto Top

Die neuesten Dateien mit der Größen-Summe von 4GB innerhalb eines Verzeichnisses filtern?

Hallo,
ich bin zwar hier ein neuer Schreiber, aber dafür ein schon sehr alter Leser face-smile

Im Moment grüble ich über einer DOS-Batch, welche mir beim DVD-brennen helfen soll.
Und zwar ist es für mich wichtig, dass die neuesten 4 GB (oder 4,3 GB) eines festgelegten Verzeichnisses auf DVD gebrannt werden.

Ich hab mir vorgestellt (bessere Ideen sind natürlich willkommen), dass alle älteren Dateien welche die (Verzeichnis-)Größe von 4,3 GB überschreiten würden in ein anderes Verzeichnis gemovet werden.

Mein bisheriges Ergebnis:

@echo off & setlocal enabledelayedexpansion
for /f "delims=" %%i in ('dir /-C /O-D /TC /B') do ((
set /a mb=!size!+%%~zi
set /A size=mb
)
if !mb! GTR 4617089843 move "%%~fi" g:\alte_Sicherung\
)


Diese Befehle machen immerhin was face-smile
Allerdings nicht zuverlässig. Wenn man es öfters über ein Verzeichnis laufen lässt, dann werden immer mehr Dateien daraus gemovet, obwohl es nicht nötig wäre face-sad
Ausserdem stimmt was mit der Sortierung nicht. Es werden Dateien stehen gelassen, welche schon älter sind und eigentlich gemovet werden könnten.

Im Moment bin ich irgendwie blind.
Vielleicht hat von euch einer einen kleinen Schubs für mich?

Gruß und Dank
Herbert

Content-ID: 84710

Url: https://administrator.de/contentid/84710

Ausgedruckt am: 22.11.2024 um 20:11 Uhr

bastla
bastla 04.04.2008 um 14:28:21 Uhr
Goto Top
Hallo herbert-m und willkommen im Forum auch als Schreiber!

Villeicht sorgt der folgende Beispielsbatch für den ersten kleinen Schubs face-wink:
set /a mb=2147483647
echo %mb%
set /a mb=%mb%+1
echo %mb%
set /a mb=%mb%+1
echo %mb%
set /a mb=4294967294
echo %mb%
set /a mb=4294967295

Grüße
bastla
Biber
Biber 04.04.2008 um 15:00:27 Uhr
Goto Top
... wobei Erbsenzähler wie ich vielleicht noch ergänzen würden,
dass das Ende der Fahnenstange für die CMD.exe mit (2 hoch 31) -1 = 2147483647 erreicht ist.

[OT]
Die gute Nachricht dabei ist.
Andere (kostenpflichtige!) M$-Programme haben noch wesentlich kleinere (Zweierpotenzen minus 1) als Grenze.
So z.B. das M$-Access mit seinen vielen 256-minus-1-Restriktionen (Tabellen, Locks, Zugriffe,..).
[/OT]

Anyhow, dieser vermeintliche Bug ist also nicht XCopy anzulasten - das ist eine CMD-Restriktion.

Grüße
Biber
bastla
bastla 04.04.2008 um 15:18:23 Uhr
Goto Top
@Biber

Wieso denn Erbsenzähler? Als solcher hättest Du doch vermutlich auch noch darauf hingewiesen, dass noch nicht einmal die Meldung
Ungültige Zahl. Zahlen sind begrenzt auf eine Genauigkeit von 32 Bits.
fehlerhaft, sondern eben so zu interpretieren ist, dass die aus den 32 Bit gebildete Zahl "signed" ("vorzeichenbehaftet") ist (woraus sich die inzwischen mehrfach erwähnte Obergrenze von 2147483647 für positive Zahlen ergibt). face-wink

Grüße
bastla
Biber
Biber 04.04.2008 um 15:41:43 Uhr
Goto Top
Na ja, bastla,

wie dem auch sei, als nächstes wäre dann ja zu prüfen, ob diese 32-Bit-Restriktion wirklich nur für das Skripting-Hilfsmittel CMD.exe gilt (wie ich behauptet habe) und dort auch nur für das "Rechnen".
Da ich hier zwar einen XP-Rechner habe, aber keine 4-Gigabyte-Dateiklötze, kann ich leider nicht prüfen, ob denn die Dateigröße (die ja mit "%%~zi" ermittelt wird) wenigstens richtig angezeigt wird.

Wenn ja, ließe sich ja auch im Batch ein (wenn auch hässlicher) Workaround schreiben mit "wenn die Stringlänge von Dateigröße länger als x Zeichen ist und die erste Ziffer größer als 1, dann...".

Aber ob die "%%~zi"-Auflösung noch funktioniert, das muss uns wohl herbert-m sagen.
....es sei denn, Du hast noch ein paar 4,3 GByte-große VBS-Schnipsel rumliegen...

Grüße
Biber
bastla
bastla 04.04.2008 um 19:34:45 Uhr
Goto Top
@Biber

... ob denn die Dateigröße (die ja mit "%%~zi" ermittelt wird) wenigstens richtig angezeigt wird.
Anzeige klappt auch mit > 6 GB

....es sei denn, Du hast noch ein paar 4,3 GByte-große VBS-Schnipsel rumliegen...
Zum Testen habe ich denen mal den Typ ".mpv" gegeben ... face-wink

Falls herbert-m aber nicht auch einzelne Dateien mit mehr als 2 GB hat, sollte es ja auch genügen, die ermittelte Dateigröße durch eine Division (etwa durch 1000) auf eine auch für CMD verträgliche Größe zu bringen - es ginge ja dann nur um's Aufsummieren, und die entstehenden Rundungsfehler würden schon nicht das ganze Konzept über den Haufen werfen...

Grüße
bastla
herbert-m
herbert-m 05.04.2008 um 08:36:08 Uhr
Goto Top
Hallo,
sehenden Auges bin ich gegen den Baum gerannt! face-sad
Hab mir die Zahlen ja beim Testen anzeigen lassen, denke mir noch 'Ah ja, da zwickts noch mit der Größenbeschränkung, 'musst halt dividieren' ... lass es aber momentan so, weil man ja kein Erbsenzähler sein will face-wink

Habs dann gestern gleich ausprobiert und bin zufrieden ins Bett gegangen face-wink

Nun sieht das so aus:

@echo off & setlocal enabledelayedexpansion
cd g:\Sicherung
g:
for /f "delims=" %%i in ('dir g:\Sicherung /-C /O-D /TC /B') do ((
set /A div=%%~zi/1000
set /a mb=!size!+!div!
set /A size=mb
)
if !mb! GTR 4617089 move "%%~fi" g:\sicherung_alt
)

Zur Erklärung:
Es geht um RAR-Archive mit einer Größe von ca. 300-350 MB, welche jeweils als Sicherung nach dem Abmelden des letzten Users erstellt werden.

Vielen Dank für den Schubs
Herbert