6
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
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
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
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
ich bin zwar hier ein neuer Schreiber, aber dafür ein schon sehr alter Leser
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
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 84710
Url: https://administrator.de/forum/die-neuesten-dateien-mit-der-groessen-summe-von-4gb-innerhalb-eines-verzeichnisses-filtern-84710.html
Ausgedruckt am: 23.12.2024 um 07:12 Uhr
6 Kommentare
Neuester Kommentar
Hallo herbert-m und willkommen im Forum auch als Schreiber!
Villeicht sorgt der folgende Beispielsbatch für den ersten kleinen Schubs
:
Grüße
bastla
Villeicht sorgt der folgende Beispielsbatch für den ersten kleinen Schubs
: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=4294967295Grüße
bastla
... 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
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
@Biber
Wieso denn Erbsenzähler? Als solcher hättest Du doch vermutlich auch noch darauf hingewiesen, dass noch nicht einmal die Meldung
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).
Grüße
bastla
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.Grüße
bastla
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
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
@Biber
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
... 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 ... 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
Hallo,
sehenden Auges bin ich gegen den Baum gerannt!
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
Habs dann gestern gleich ausprobiert und bin zufrieden ins Bett gegangen
Nun sieht das so aus:
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
sehenden Auges bin ich gegen den Baum gerannt!
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
Habs dann gestern gleich ausprobiert und bin zufrieden ins Bett gegangen
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
)
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
