/dev/null
- Overig
vind exact zelfde bestand snel
22-02-2020, 11:19 door Anoniem, 49 reacties
dag,
kent iemand software waarmee je snel een identiek bestand kan vinden (dat mogelijk onder een andere naam ergens staat)?
ik gebruik al wizfile, everything, fast duplicate file finder en zoekprogramma's als agent ransack etc.
Maar die programma's hebben nadelen: ik moet het programma helemaal en handmatig instellen op de eigenschappen van het bestand waarvan ik het identieke exemplaar zoek. dat kan, maar dat is dus niet wat ik bedoel met 'snel'.
wat ik zou willen is een programma waar je een bestandje op kan droppen waarna het programma razendsnel en automatisch op basis van de uitgelezen eigenschappen het duplicaat zoekt.
nogmaals: everything etc etc gebruik ik al.
zo'n programma zag ik nog niet. iemand anders wel?
kent iemand software waarmee je snel een identiek bestand kan vinden (dat mogelijk onder een andere naam ergens staat)?
ik gebruik al wizfile, everything, fast duplicate file finder en zoekprogramma's als agent ransack etc.
Maar die programma's hebben nadelen: ik moet het programma helemaal en handmatig instellen op de eigenschappen van het bestand waarvan ik het identieke exemplaar zoek. dat kan, maar dat is dus niet wat ik bedoel met 'snel'.
wat ik zou willen is een programma waar je een bestandje op kan droppen waarna het programma razendsnel en automatisch op basis van de uitgelezen eigenschappen het duplicaat zoekt.
nogmaals: everything etc etc gebruik ik al.
zo'n programma zag ik nog niet. iemand anders wel?
Reacties (49)
22-02-2020, 13:00 door
Tintin and Milou
Nu heb ik geen idee wat dit met security te maken heeft?
Maar oke....
Maar welk OS gebruik je? Kan nog wel eens van belang zijn voor de applicaties
Daarnaast, waarop bepaal je dat dit een duplicaat is? Op basis van de inhoud, of de bestandsnaam? Je geeft aan uitgelezen eigenschappen... Maar wat versta je exact hieronder?
Daar staat de data? lokaal, netwerk? Database? Webbased?
Was is ook je definitie van snel? 1 seconden, 10 seconden? Minuten?
Over hoeveel bestanden hebben het?
Hoevaak update de dataset en moet er dus opnieuw geïnventariseerd worden.
Maar oke....
Maar welk OS gebruik je? Kan nog wel eens van belang zijn voor de applicaties
Daarnaast, waarop bepaal je dat dit een duplicaat is? Op basis van de inhoud, of de bestandsnaam? Je geeft aan uitgelezen eigenschappen... Maar wat versta je exact hieronder?
Daar staat de data? lokaal, netwerk? Database? Webbased?
Was is ook je definitie van snel? 1 seconden, 10 seconden? Minuten?
Over hoeveel bestanden hebben het?
Hoevaak update de dataset en moet er dus opnieuw geïnventariseerd worden.
Je zult dan toch eerst alle files geïndexeerd moeten hebben. Het is tenslotte mogelijk dat twee bestanden bijna identiek zijn (bestand grootte), maar de laatste byte is anders.
Een index hier bestaat dan uit een hash van de file en de file-naam. Daarna kun je de duplicaten snel vinden op basis van gelijke hash.
Een index hier bestaat dan uit een hash van de file en de file-naam. Daarna kun je de duplicaten snel vinden op basis van gelijke hash.
Tja wat is hardstikke snel. Je moet uiteraard wel op zoek naar bestanden en ze wellicht ook lezen. Hier is wel e.e.a.
aan te optimaliseren (het bestand kan alleen exact gelijk zijn als de grootte ook gelijk is dus veel bestanden vallen af).
Ik heb ooit wel eens een programma gemaakt dat in een hele directory tree alle bestanden afdrukt die hoogstwaarschijnlijk
gelijk zijn. Daarbij sla ik bestanden van 0 bytes over want die zijn altijd gelijk en die wil je meestal niet zien.
Dat programma is heel simpel dus ik kan het meteen bijvoegen:
#!/bin/sh
find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //'
Dit start je op met de startdirectory als parameter en het geeft als output de namen van bestanden die wellicht dups zijn.
aan te optimaliseren (het bestand kan alleen exact gelijk zijn als de grootte ook gelijk is dus veel bestanden vallen af).
Ik heb ooit wel eens een programma gemaakt dat in een hele directory tree alle bestanden afdrukt die hoogstwaarschijnlijk
gelijk zijn. Daarbij sla ik bestanden van 0 bytes over want die zijn altijd gelijk en die wil je meestal niet zien.
Dat programma is heel simpel dus ik kan het meteen bijvoegen:
#!/bin/sh
find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //'
Dit start je op met de startdirectory als parameter en het geeft als output de namen van bestanden die wellicht dups zijn.
Door Anoniem: Tja wat is hardstikke snel. Je moet uiteraard wel op zoek naar bestanden en ze wellicht ook lezen. Hier is wel e.e.a.
aan te optimaliseren (het bestand kan alleen exact gelijk zijn als de grootte ook gelijk is dus veel bestanden vallen af).
Ik heb ooit wel eens een programma gemaakt dat in een hele directory tree alle bestanden afdrukt die hoogstwaarschijnlijk
gelijk zijn. Daarbij sla ik bestanden van 0 bytes over want die zijn altijd gelijk en die wil je meestal niet zien.
Dat programma is heel simpel dus ik kan het meteen bijvoegen:
#!/bin/sh
find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //'
Dit start je op met de startdirectory als parameter en het geeft als output de namen van bestanden die wellicht dups zijn.
aan te optimaliseren (het bestand kan alleen exact gelijk zijn als de grootte ook gelijk is dus veel bestanden vallen af).
Ik heb ooit wel eens een programma gemaakt dat in een hele directory tree alle bestanden afdrukt die hoogstwaarschijnlijk
gelijk zijn. Daarbij sla ik bestanden van 0 bytes over want die zijn altijd gelijk en die wil je meestal niet zien.
Dat programma is heel simpel dus ik kan het meteen bijvoegen:
#!/bin/sh
find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //'
Dit start je op met de startdirectory als parameter en het geeft als output de namen van bestanden die wellicht dups zijn.
Hoe vet! Dit werkt goed, thanks! Als ik zo' ascii duimpje kon maken zou ik het doen.
Top!
hoi, veel dank hoor.
ik werk met windows 10. mijn vraag heeft idd niks met security te maken, maar ik dacht dat dat ok was op dit subforum /dev/null.
uitgelezen eigenschappen: filegrootte, de verschillende file-datums, filetype...
dit is linux-code klopt?
#!/bin/sh
find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //
bedankt weer, groeten
ik werk met windows 10. mijn vraag heeft idd niks met security te maken, maar ik dacht dat dat ok was op dit subforum /dev/null.
uitgelezen eigenschappen: filegrootte, de verschillende file-datums, filetype...
dit is linux-code klopt?
#!/bin/sh
find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //
bedankt weer, groeten
Door Anoniem: hoi, veel dank hoor.
ik werk met windows 10. mijn vraag heeft idd niks met security te maken, maar ik dacht dat dat ok was op dit subforum /dev/null.
uitgelezen eigenschappen: filegrootte, de verschillende file-datums, filetype...
dit is linux-code klopt?
#!/bin/sh
find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //
bedankt weer, groeten
ik werk met windows 10. mijn vraag heeft idd niks met security te maken, maar ik dacht dat dat ok was op dit subforum /dev/null.
uitgelezen eigenschappen: filegrootte, de verschillende file-datums, filetype...
dit is linux-code klopt?
#!/bin/sh
find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //
bedankt weer, groeten
Windows heeft powershell, er is vast wel een Windows adept die bovenstaande even om kan zetten naar die 'krachtige' Windows shell? Bovendien, heeft Windows tegenwoordig geen bash shell?
Bovendien, heeft Windows tegenwoordig geen bash shell?
heb ik even nagezocht, inderdaad.... leuk.
dus ik zou de code moeten kunnen runnen. eens kijken of dat werkt (gaat ff duren)
bedankt nog eens een keer
heb ik even nagezocht, inderdaad.... leuk.
dus ik zou de code moeten kunnen runnen. eens kijken of dat werkt (gaat ff duren)
bedankt nog eens een keer
22-02-2020, 22:51 door
The FOSS
Door Anoniem:
heb ik even nagezocht, inderdaad.... leuk.
dus ik zou de code moeten kunnen runnen. eens kijken of dat werkt (gaat ff duren)
bedankt nog eens een keer
Door The FOSS: Bovendien, heeft Windows tegenwoordig geen bash shell?
heb ik even nagezocht, inderdaad.... leuk.
dus ik zou de code moeten kunnen runnen. eens kijken of dat werkt (gaat ff duren)
bedankt nog eens een keer
You're welcome. Koppel hier nog even terug of het werkt? (Ik ben benieuwd).
https://social.technet.microsoft.com/wiki/contents/articles/52270.windows-powershell-how-to-find-duplicate-files.aspx
Lijst maken van de CRC32 van alle bestanden, en dan in kladblok zoeken?
23-02-2020, 09:06 door
The FOSS
Door The FOSS:
You're welcome. Koppel hier nog even terug of het werkt? (Ik ben benieuwd).
Door Anoniem:
heb ik even nagezocht, inderdaad.... leuk.
dus ik zou de code moeten kunnen runnen. eens kijken of dat werkt (gaat ff duren)
bedankt nog eens een keer
Door The FOSS: Bovendien, heeft Windows tegenwoordig geen bash shell?
heb ik even nagezocht, inderdaad.... leuk.
dus ik zou de code moeten kunnen runnen. eens kijken of dat werkt (gaat ff duren)
bedankt nog eens een keer
You're welcome. Koppel hier nog even terug of het werkt? (Ik ben benieuwd).
N.B. Als het niet werkt dan kan je altijd nog Cygwin [*] installeren. Daarmee werkt het gegarandeerd.
[*] https://www.cygwin.com/
Door Anoniem: https://social.technet.microsoft.com/wiki/contents/articles/52270.windows-powershell-how-to-find-duplicate-files.aspx
zo zo...
$Path = '\\PDC\Shared\Accounting' #define path to folders to find duplicate files
$Files=gci -File -Recurse -path $Path | Select-Object -property FullName,Length
$Count=1
$TotalFiles=$Files.Count
$MatchedSourceFiles=@()
ForEach ($SourceFile in $Files)
{
Write-Progress -Activity "Processing Files" -status "Processing File $Count / $TotalFiles" -PercentComplete ($Count / $TotalFiles * 100)
$MatchingFiles=@()
$MatchingFiles=$Files |Where-Object {$_.Length -eq $SourceFile.Length}
Foreach ($TargetFile in $MatchingFiles)
{
if (($SourceFile.FullName -ne $TargetFile.FullName) -and !(($MatchedSourceFiles |
Select-Object -ExpandProperty File) -contains $TargetFile.FullName))
{
Write-Verbose "Matching $($SourceFile.FullName) and $($TargetFile.FullName)"
Write-Verbose "File sizes match."
if ((fc.exe /A $SourceFile.FullName $TargetFile.FullName) -contains "FC: no differences encountered")
{
Write-Verbose "Match found."
$MatchingFiles+=$TargetFile.FullName
}
}
}
if ($MatchingFiles.Count -gt 0)
{
$NewObject=[pscustomobject][ordered]@{
File=$SourceFile.FullName
MatchingFiles=$MatchingFiles
}
$MatchedSourceFiles+=$NewObject
}
$Count+=1
}
$MatchedSourceFiles
$Files=gci -File -Recurse -path $Path | Select-Object -property FullName,Length
$Count=1
$TotalFiles=$Files.Count
$MatchedSourceFiles=@()
ForEach ($SourceFile in $Files)
{
Write-Progress -Activity "Processing Files" -status "Processing File $Count / $TotalFiles" -PercentComplete ($Count / $TotalFiles * 100)
$MatchingFiles=@()
$MatchingFiles=$Files |Where-Object {$_.Length -eq $SourceFile.Length}
Foreach ($TargetFile in $MatchingFiles)
{
if (($SourceFile.FullName -ne $TargetFile.FullName) -and !(($MatchedSourceFiles |
Select-Object -ExpandProperty File) -contains $TargetFile.FullName))
{
Write-Verbose "Matching $($SourceFile.FullName) and $($TargetFile.FullName)"
Write-Verbose "File sizes match."
if ((fc.exe /A $SourceFile.FullName $TargetFile.FullName) -contains "FC: no differences encountered")
{
Write-Verbose "Match found."
$MatchingFiles+=$TargetFile.FullName
}
}
}
if ($MatchingFiles.Count -gt 0)
{
$NewObject=[pscustomobject][ordered]@{
File=$SourceFile.FullName
MatchingFiles=$MatchingFiles
}
$MatchedSourceFiles+=$NewObject
}
$Count+=1
}
$MatchedSourceFiles
en dan is een bash oneliner te lastig? ik bedoel, dit soort dingen zie ik de std windows admin niet even vlug doen, maar die ene bash regel die voorbij is gekomen, daar maken de meeste unix admins nog niet eens een script van omdat die zo 'triviaal' is eigenlijk...
23-02-2020, 11:31 door
Tintin and Milou
Door Anoniem:
zo zo...
en dan is een bash oneliner te lastig? ik bedoel, dit soort dingen zie ik de std windows admin niet even vlug doen, maar die ene bash regel die voorbij is gekomen, daar maken de meeste unix admins nog niet eens een script van omdat die zo 'triviaal' is eigenlijk...
Door Anoniem: https://social.technet.microsoft.com/wiki/contents/articles/52270.windows-powershell-how-to-find-duplicate-files.aspx
zo zo...
$Path = '\\PDC\Shared\Accounting' #define path to folders to find duplicate files
$Files=gci -File -Recurse -path $Path | Select-Object -property FullName,Length
..........
}
$MatchedSourceFiles
$Files=gci -File -Recurse -path $Path | Select-Object -property FullName,Length
..........
}
$MatchedSourceFiles
en dan is een bash oneliner te lastig? ik bedoel, dit soort dingen zie ik de std windows admin niet even vlug doen, maar die ene bash regel die voorbij is gekomen, daar maken de meeste unix admins nog niet eens een script van omdat die zo 'triviaal' is eigenlijk...
Get-ChildItem -Recurse -File | Group-Object Length | Where-Object { $_.Count -gt 1 } | select -ExpandProperty group | foreach {Get-FileHash -LiteralPath $_.FullName} | group -Property hash | where { $_.count -gt 1 } | select -ExpandProperty group
Alternatief, kortere oneliner, en gemakkelijker te lezen:
gci -Recurse -file | Group-Object name | Where-Object { $_.Count -gt 1 } | select -ExpandProperty group | %{ $_.fullname }
Maar er zijn nogmeer mogelijkheden te vinden op, waar ik deze ook heb gevonden:
https://stackoverflow.com/questions/49666204/powershell-to-display-duplicate-files
Door Anoniem: #!/bin/sh
find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //'
Mooie one-liner.find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //'
Omdat ik zelf in de loop van de tijd ook af en toe behoefte aan zo'n tool had, zowel de vraagsteller als dit en andere antwoorden een praktische richting aangeven, en omdat ik het leuk vind om in Python te knutselen heb ik me daarstraks even kwaad gemaakt met het volgende resultaat:
#!/usr/bin/env python3
"""
Find duplicate files.
Usage:
{script} [path...] [-- cmd [arg...]]
{script} --help
The path arguments can be either directories or regular files. If any
directories are given they serve as roots for the search: only files within
those directories and their subdirectories are compared. If no roots are given
the current directory is used as a root.
If regular files are given only those files and their duplicates are reported.
Paths of duplicate files are printed to stdout, one path per line, with empty
lines between groups of duplicates, unless '--' is given, then the command
specified is executed for each group, with the arguments specified, followed by
the pathnames for the group.
Empty files and symbolic links are ignored.
If --help is given this help text is printed.
"""
import sys
import pathlib
import hashlib
import itertools
import operator
import subprocess
def helptext():
return __doc__.format(script=pathlib.Path(sys.argv[0]).name)
def by_size(path):
return path.stat().st_size
def by_hash(path):
try:
return hashlib.sha1(path.read_bytes()).digest()
except IOError as ex:
print('Error reading {}: {}'.format(path, ex), file=sys.stderr)
return None
def find_dupes(paths, keyfunc):
items = ((keyfunc(path), path) for path in paths)
items = sorted((key, path) for key, path in items if key is not None)
groups = [[i[1] for i in g]
for k, g in itertools.groupby(items, key=operator.itemgetter(0))]
yield from (group for group in groups if len(group) > 1)
def parse_args(args):
args = sys.argv[1:]
if '--help' in args:
print(helptext())
sys.exit()
if '--' in args:
pos = args.index('--')
paths = args[:pos]
cmd = args[pos + 1:]
else:
paths = args
cmd = None
paths = [pathlib.Path(p) for p in paths]
roots = [p for p in paths if p.is_dir()]
match = [p for p in paths if p not in roots]
for p in match:
if not p.is_file():
sys.exit('ERROR, not a file: {}\n{}'.format(p, helptext()))
if not roots:
roots = ['.']
return roots, match, cmd
def main():
roots, match, cmd = parse_args(sys.argv[1:])
paths = (path
for root in roots
for path in pathlib.Path(root).glob('**/*')
if path.is_file()
and not path.is_symlink()
and path.stat().st_size != 0)
same_size = find_dupes(paths, by_size)
if match:
same_size = (group
for group in same_size
if any(m in group for m in match))
same_hash = (group
for sgroup in same_size
for group in find_dupes(sgroup, by_hash))
if match:
same_hash = (group
for group in same_hash
if any(m in group for m in match))
if cmd:
for group in same_hash:
subprocess.run(cmd + group)
else:
for group in same_hash:
for path in sorted(group):
print(path)
print()
if __name__ == '__main__':
main()
Het is op de commandline op de volgende manieren gebruiken:"""
Find duplicate files.
Usage:
{script} [path...] [-- cmd [arg...]]
{script} --help
The path arguments can be either directories or regular files. If any
directories are given they serve as roots for the search: only files within
those directories and their subdirectories are compared. If no roots are given
the current directory is used as a root.
If regular files are given only those files and their duplicates are reported.
Paths of duplicate files are printed to stdout, one path per line, with empty
lines between groups of duplicates, unless '--' is given, then the command
specified is executed for each group, with the arguments specified, followed by
the pathnames for the group.
Empty files and symbolic links are ignored.
If --help is given this help text is printed.
"""
import sys
import pathlib
import hashlib
import itertools
import operator
import subprocess
def helptext():
return __doc__.format(script=pathlib.Path(sys.argv[0]).name)
def by_size(path):
return path.stat().st_size
def by_hash(path):
try:
return hashlib.sha1(path.read_bytes()).digest()
except IOError as ex:
print('Error reading {}: {}'.format(path, ex), file=sys.stderr)
return None
def find_dupes(paths, keyfunc):
items = ((keyfunc(path), path) for path in paths)
items = sorted((key, path) for key, path in items if key is not None)
groups = [[i[1] for i in g]
for k, g in itertools.groupby(items, key=operator.itemgetter(0))]
yield from (group for group in groups if len(group) > 1)
def parse_args(args):
args = sys.argv[1:]
if '--help' in args:
print(helptext())
sys.exit()
if '--' in args:
pos = args.index('--')
paths = args[:pos]
cmd = args[pos + 1:]
else:
paths = args
cmd = None
paths = [pathlib.Path(p) for p in paths]
roots = [p for p in paths if p.is_dir()]
match = [p for p in paths if p not in roots]
for p in match:
if not p.is_file():
sys.exit('ERROR, not a file: {}\n{}'.format(p, helptext()))
if not roots:
roots = ['.']
return roots, match, cmd
def main():
roots, match, cmd = parse_args(sys.argv[1:])
paths = (path
for root in roots
for path in pathlib.Path(root).glob('**/*')
if path.is_file()
and not path.is_symlink()
and path.stat().st_size != 0)
same_size = find_dupes(paths, by_size)
if match:
same_size = (group
for group in same_size
if any(m in group for m in match))
same_hash = (group
for sgroup in same_size
for group in find_dupes(sgroup, by_hash))
if match:
same_hash = (group
for group in same_hash
if any(m in group for m in match))
if cmd:
for group in same_hash:
subprocess.run(cmd + group)
else:
for group in same_hash:
for path in sorted(group):
print(path)
print()
if __name__ == '__main__':
main()
• Zonder argumenten zoekt het in de current directory en alle subdirectories naar identieke bestanden, en laat ze zien als groepje identieke bestanden met één bestand per regel en lege regels tussen de groepjes.
• Als je een of meer directory's als commandline-argumenten meegeeft dan worden die doorzocht in plaats van de current directory.
• Als je een of meer bestanden als commandline-argumenten meegeeft dan dienen die als filter: alleen de groepjes overeenkomende bestanden waarin minstens een van die bestandsnamen voorkomt worden gerapporteerd.
• De bestands- en directorynamen uit de vorige twee punten mogen door elkaar worden opgegeven.
• Achteraan de argumenten kan '--' worden toegevoegd met daarachter een commando en argumenten die voor elke gevonden groep bestanden worden uitgevoerd. De bestandsnamen uit die groep worden aan de argumenten toegevoegd.
Ik heb dit op Linux uitgewerkt, gebruikmakend van Python 3.7. Ik heb volgens mij niets Linux-specifieks gebruikt, dus zou dit op een Windows-systeem met een voldoende recente versie van Python3 erop moeten werken. Of je er in Windows een uitvoerbaar script-commando van kan maken zoals dat op Linux/Unix mogelijk is moet iemand die daarin thuis is maar vertellen, want ik weet dat niet.
Er wordt eerst naar de file size gekeken en pas als die overeenkomt worden hashes (sha1) berekend om de inhoud mee te vergelijken. Lege bestanden en symbolic links worden overgeslagen.
Voor wie de code probeert te doorgronden zonder thuis te zijn in Python: ik gebruik het feit dat je in Python referenties aan functies als argumenten kan meegeven aan andere functies. De functie die "yield" in plaats van "return" bevat voor het resultaat is een zogenaamde "generator", die niet één resultaat teruggeeft maar een stroom resultaten. Verder leunt de verwerking zwaar op zogenaamde "list comprehensions" en "generator expressions", dat zijn de expressies die eruit zien als combinaties van for-loops en if-statements die tussen respectievelijk blokhaken en ronde haken staan. Als je naar die termen zoekt is er online volop uitleg erover te vinden.
De voor deze toepassing nuttige magie van generator expressions is dat ze het mogelijk maken om acties die complete loops vormen als statements te noteren die lezen alsof ze een voor een worden uitgevoerd, met zelfs optionele bewerkingen ertussen, terwijl ze op runtime een pijplijn vormen waarin de verwerkte items stuk voor stuk door opeenvolgende bewerkingen worden getrokken. Voor dit programma betekent dat dat de resultaten niet pas getoond worden als alle hashes zijn berekend maar al vrij snel beginnen te verschijnen (wel moeten alle file sizes al opgezocht zijn), terwijl het geheugengebruik ook bij grote verzamelingen bestanden binnen de perken blijft omdat niet alle tussenresultaten in geheugen bewaard hoeven te blijven. Voor kenners van functionele programmeertalen als Haskell: zo ziet lazy evaluation eruit in Python.
Door Tintin and Milou:
Alternatief, kortere oneliner, en gemakkelijker te lezen:
Maar er zijn nogmeer mogelijkheden te vinden op, waar ik deze ook heb gevonden:
https://stackoverflow.com/questions/49666204/powershell-to-display-duplicate-files
Door Anoniem:
zo zo...
en dan is een bash oneliner te lastig? ik bedoel, dit soort dingen zie ik de std windows admin niet even vlug doen, maar die ene bash regel die voorbij is gekomen, daar maken de meeste unix admins nog niet eens een script van omdat die zo 'triviaal' is eigenlijk...
Door Anoniem: https://social.technet.microsoft.com/wiki/contents/articles/52270.windows-powershell-how-to-find-duplicate-files.aspx
zo zo...
$Path = '\\PDC\Shared\Accounting' #define path to folders to find duplicate files
$Files=gci -File -Recurse -path $Path | Select-Object -property FullName,Length
..........
}
$MatchedSourceFiles
$Files=gci -File -Recurse -path $Path | Select-Object -property FullName,Length
..........
}
$MatchedSourceFiles
en dan is een bash oneliner te lastig? ik bedoel, dit soort dingen zie ik de std windows admin niet even vlug doen, maar die ene bash regel die voorbij is gekomen, daar maken de meeste unix admins nog niet eens een script van omdat die zo 'triviaal' is eigenlijk...
Get-ChildItem -Recurse -File | Group-Object Length | Where-Object { $_.Count -gt 1 } | select -ExpandProperty group | foreach {Get-FileHash -LiteralPath $_.FullName} | group -Property hash | where { $_.count -gt 1 } | select -ExpandProperty group
Alternatief, kortere oneliner, en gemakkelijker te lezen:
gci -Recurse -file | Group-Object name | Where-Object { $_.Count -gt 1 } | select -ExpandProperty group | %{ $_.fullname }
Maar er zijn nogmeer mogelijkheden te vinden op, waar ik deze ook heb gevonden:
https://stackoverflow.com/questions/49666204/powershell-to-display-duplicate-files
die laatste kijkt niet naar hashes van files toch?
Je moet 1x alle bestanden op je systeem indexeren en de md5 hash opslaan.
Vervolgens moet je een applicatie maken die checkt op md5 hash. Zo simpel is het
Vervolgens moet je een applicatie maken die checkt op md5 hash. Zo simpel is het
24-02-2020, 11:06 door
Krakatau
Door Anoniem:
Omdat ik zelf in de loop van de tijd ook af en toe behoefte aan zo'n tool had, zowel de vraagsteller als dit en andere antwoorden een praktische richting aangeven, en omdat ik het leuk vind om in Python te knutselen heb ik me daarstraks even kwaad gemaakt met het volgende resultaat:
...
Door Anoniem: #!/bin/sh
find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //'
Mooie one-liner.find $@ -type f -size +0 -print0 | xargs -0 md5sum | sort | uniq --all-repeated=prepend -w32 | sed -e 's/^[0-9a-f]* //'
Omdat ik zelf in de loop van de tijd ook af en toe behoefte aan zo'n tool had, zowel de vraagsteller als dit en andere antwoorden een praktische richting aangeven, en omdat ik het leuk vind om in Python te knutselen heb ik me daarstraks even kwaad gemaakt met het volgende resultaat:
...
Heel mooi! Jij bent een echte Python guru!
Ik heb de programmeertaal Python nogal onderschat als ik dit zo bekijk. Misschien toch maar eens gaan leren.
Door Anoniem: Je moet 1x alle bestanden op je systeem indexeren en de md5 hash opslaan.
Vervolgens moet je een applicatie maken die checkt op md5 hash. Zo simpel is het
Werkelijk?Vervolgens moet je een applicatie maken die checkt op md5 hash. Zo simpel is het
Hoe raken nieuwe bestanden gehasht? Hoe worden verwijderde bestanden uit de verzameling hashes verwijderd? Hoe worden hashes van gewijzigde bestanden aangepast? Hoe weet je applicatie eigenlijk dat een bestand gewijzigd is? Besef je dat een gewijzigd bestand niet groter of kleiner hoeft te zijn dan de vorige versie, en wist je dat het mogelijk is om een bestand te wijzigen zonder dat de datum/tijd worden aangepast, en om die datum/tijd te wijzigen zonder dat je het bestand inhoudelijk aanpast? Hoe houd je je hashes betrouwbaar als dat soort dingen mogelijk zijn? Is het reëel om te besluiten er maar helemaal geen rekening mee te houden, of maak je daar toch liever een voorziening voor in je applicatie?
Dingen zijn niet altijd zo simpel als ze op het eerste gezicht lijken.
Je kan een heleboel van die complexiteit vermijden door maar geen hashes op te slaan en ze alleen te berekenen als ze toegevoegde waarde hebben, namelijk als bestanden dezelfde grootte blijken te hebben. Een paar proefjes met een consumenten-laptopschijfje dat 1TB in een half miljoen bestanden bevat leren dat zoeken naar duplicaten van een specifiek bestand ongeveer 3,5 minuten duurt, wat terugvalt naar 1,5 minuut voor volgende zoekacties, omdat dan alle directory-informatie al gecached is in geheugen en daarvoor de schijf niet opnieuw benaderd wordt. Misschien is dat wel meer dan snel genoeg voor acties die je hoogstwaarschijnlijk niet dag in dag uit aan het doen bent. Het is in ieder geval dramatisch veel sneller dan de hashes van alle bestanden berekenen.
"Simpel" alle hashes berekenen is als je even nadenkt misschien juist wel een onnodig gecompliceerde manier om deze toepassing te implementeren.
24-02-2020, 11:40 door
Bitje-scheef
Python is zeer gestructureerd en zeer krachtig. Wordt zelfs bij Uni's,Nasa en vele andere data-slurpers/verwerkers gebruikt.
Door Anoniem:
Hoe raken nieuwe bestanden gehasht? Hoe worden verwijderde bestanden uit de verzameling hashes verwijderd? Hoe worden hashes van gewijzigde bestanden aangepast? Hoe weet je applicatie eigenlijk dat een bestand gewijzigd is? Besef je dat een gewijzigd bestand niet groter of kleiner hoeft te zijn dan de vorige versie, en wist je dat het mogelijk is om een bestand te wijzigen zonder dat de datum/tijd worden aangepast, en om die datum/tijd te wijzigen zonder dat je het bestand inhoudelijk aanpast? Hoe houd je je hashes betrouwbaar als dat soort dingen mogelijk zijn? Is het reëel om te besluiten er maar helemaal geen rekening mee te houden, of maak je daar toch liever een voorziening voor in je applicatie?
Dingen zijn niet altijd zo simpel als ze op het eerste gezicht lijken.
Je kan een heleboel van die complexiteit vermijden door maar geen hashes op te slaan en ze alleen te berekenen als ze toegevoegde waarde hebben, namelijk als bestanden dezelfde grootte blijken te hebben. Een paar proefjes met een consumenten-laptopschijfje dat 1TB in een half miljoen bestanden bevat leren dat zoeken naar duplicaten van een specifiek bestand ongeveer 3,5 minuten duurt, wat terugvalt naar 1,5 minuut voor volgende zoekacties, omdat dan alle directory-informatie al gecached is in geheugen en daarvoor de schijf niet opnieuw benaderd wordt. Misschien is dat wel meer dan snel genoeg voor acties die je hoogstwaarschijnlijk niet dag in dag uit aan het doen bent. Het is in ieder geval dramatisch veel sneller dan de hashes van alle bestanden berekenen.
"Simpel" alle hashes berekenen is als je even nadenkt misschien juist wel een onnodig gecompliceerde manier om deze toepassing te implementeren.
Door Anoniem: Je moet 1x alle bestanden op je systeem indexeren en de md5 hash opslaan.
Vervolgens moet je een applicatie maken die checkt op md5 hash. Zo simpel is het
Werkelijk?Vervolgens moet je een applicatie maken die checkt op md5 hash. Zo simpel is het
Hoe raken nieuwe bestanden gehasht? Hoe worden verwijderde bestanden uit de verzameling hashes verwijderd? Hoe worden hashes van gewijzigde bestanden aangepast? Hoe weet je applicatie eigenlijk dat een bestand gewijzigd is? Besef je dat een gewijzigd bestand niet groter of kleiner hoeft te zijn dan de vorige versie, en wist je dat het mogelijk is om een bestand te wijzigen zonder dat de datum/tijd worden aangepast, en om die datum/tijd te wijzigen zonder dat je het bestand inhoudelijk aanpast? Hoe houd je je hashes betrouwbaar als dat soort dingen mogelijk zijn? Is het reëel om te besluiten er maar helemaal geen rekening mee te houden, of maak je daar toch liever een voorziening voor in je applicatie?
Dingen zijn niet altijd zo simpel als ze op het eerste gezicht lijken.
Je kan een heleboel van die complexiteit vermijden door maar geen hashes op te slaan en ze alleen te berekenen als ze toegevoegde waarde hebben, namelijk als bestanden dezelfde grootte blijken te hebben. Een paar proefjes met een consumenten-laptopschijfje dat 1TB in een half miljoen bestanden bevat leren dat zoeken naar duplicaten van een specifiek bestand ongeveer 3,5 minuten duurt, wat terugvalt naar 1,5 minuut voor volgende zoekacties, omdat dan alle directory-informatie al gecached is in geheugen en daarvoor de schijf niet opnieuw benaderd wordt. Misschien is dat wel meer dan snel genoeg voor acties die je hoogstwaarschijnlijk niet dag in dag uit aan het doen bent. Het is in ieder geval dramatisch veel sneller dan de hashes van alle bestanden berekenen.
"Simpel" alle hashes berekenen is als je even nadenkt misschien juist wel een onnodig gecompliceerde manier om deze toepassing te implementeren.
was er nu maar een file systeem die bij het aanmaken of veranderen van een file meteen een hash van de data en meta data bijhoudt. als i het maar om corruptie te detekteren, je zou die hashes meteen kunnen gebruiken voor een tool zoals TS zoekt.
Door Krakatau: Heel mooi! Jij bent een echte Python guru!
Dank je! Ik heb de programmeertaal Python nogal onderschat als ik dit zo bekijk. Misschien toch maar eens gaan leren.
Dat soort onderschatting zie ik opvallend vaak, met name onder mensen die een bloedhekel aan Python hebben en kankeren over wat er in hun ogen allemaal mis mee is. Mij valt dan altijd op dat ze a) Python niet meer dan heel oppervlakkig kennen, ze hebben er amper aan geroken; en b) denken dat hoe ze gewend zijn dat iets in de taal of talen die ze gewend zijn werkt, en in tools die op die talen gericht zijn, de enig mogelijke juiste manier is: wat ze kennen is hoe het hoort en wat daarvan afwijkt moet kennelijk bestreden worden.De grootste haat is tegen het ontbreken van accolades om blokken statements te markeren, maar daarvoor inspringen te gebruiken. Dat levert problemen op als die inspringing ergens niet goed wordt weergegeven (zoals tot voor kort op deze website) of bij kopiëren en plakken overhoop gehaald wordt (er zijn editors die iets te intelligent proberen te plakken en er een puinhoop van maken). Het is verder verdomd onhandig als je editor niet in staat is om het inspringen van een blok geselecteerde regels in een handeling te vergroten of te verkleinen en je dat regel voor regel moet doen. Ik gebruik vim: een crime om te leren maar na pakweg twee weken worstelen in toenemende mate een feest om mee te werken en perfect voor Python.
Programmeurs die accolades gewend zijn gebruiken tools om de indentatie van de code aan accolades aan te passen, en hun wereldje stort ongeveer in als dat niet meer kan. Ik ben juist altijd iemand geweest die het eigenlijk volstrekt idioot vond dat er met accolades aan de compiler wordt verteld hoe de code gestructureerd is en parallel daaraan met inspringen precies hetzelfde aan mensen: twee conventies om precies hetzelfde aan te geven die met elkaar uit de pas kunnen lopen, terwijl het hele punt van een programmeertaal is (dat geldt zelfs al voor assembler) om een brug te slaan tussen wat de computer nodig heeft en wat voor mensen hanteerbaar is. Voor mij is indentatie om blokken aan te geven een volkomen logische manier om die brug te slaan, en het ontbreken van de visuele ruis van al die accolades vind ik een verademing. Bij anderen slaan juist de stoppen door als ze zoiets zien.
Rare jongens, die programmeurs ;-)
Door Anoniem: Je moet 1x alle bestanden op je systeem indexeren en de md5 hash opslaan.
Vervolgens moet je een applicatie maken die checkt op md5 hash. Zo simpel is het
Vervolgens moet je een applicatie maken die checkt op md5 hash. Zo simpel is het
En die md5-waarde plak je dan gewoon achter de originele bestandsnaam.
Als dit met alle bestanden is gebeurt, kan je daarna met de normale search-manier zoeken of een bepaalde hashwaarde
vaker in een bestandsnaam voorkomt.
Tegelijk is het meteen ook een integriteitscontrole: na kopiëren, backup/restore e.d. moeten de hashwaarden in de bestandsnamen altijd kloppen met de daadwerkelijke hash van elk bestand.
Een addertje is nog wel dat soms een md5-collission optreedt met als resultaat een false positive.
Deze kans is geringer door een sterkere hash te gebruiken. (bijv. SHA1, 2 of 3)
Door Anoniem:
[..]
was er nu maar een file systeem die bij het aanmaken of veranderen van een file meteen een hash van de data en meta data bijhoudt. als i het maar om corruptie te detekteren, je zou die hashes meteen kunnen gebruiken voor een tool zoals TS zoekt.
[..]
was er nu maar een file systeem die bij het aanmaken of veranderen van een file meteen een hash van de data en meta data bijhoudt. als i het maar om corruptie te detekteren, je zou die hashes meteen kunnen gebruiken voor een tool zoals TS zoekt.
Je weet dat je een file op een willekeurige plek kunt beschrijven, eraan kunt appenden , en files van enorme grootte kunt aanmaken zonder direct die hele file te schrijven [sparse file] ?
Waar je om vraagt betekent dat elke logregel die je in /var/log/messages erbij schrijft betekent dat de hele file gelezen moet worden om de (nieuwe) hash te berekenen.
Idem voor de heel grote files (feitelijk storage containers) waaruit een database is opgebouwd.
Dus nee, Niet Handig om elke schrijfactie te laten leiden tot het volledig lezen van de file die beschreven wordt.
Door Anoniem: was er nu maar een file systeem die bij het aanmaken of veranderen van een file meteen een hash van de data en meta data bijhoudt. als i het maar om corruptie te detekteren, je zou die hashes meteen kunnen gebruiken voor een tool zoals TS zoekt.
Er zijn filesystemen die op blokniveau checksums berekenen, zoals btrfs en zfs, maar dat zijn geen cryptografische hashfuncties maar bijvoorbeeld crc32c. Die zijn prima geschikt voor een integriteitscheck van de data maar niet voor het doel van TS.Door Anoniem: Je weet dat je een file op een willekeurige plek kunt beschrijven, eraan kunt appenden , en files van enorme grootte kunt aanmaken zonder direct die hele file te schrijven [sparse file] ?
Waar je om vraagt betekent dat elke logregel die je in /var/log/messages erbij schrijft betekent dat de hele file gelezen moet worden om de (nieuwe) hash te berekenen.
Je hebt groot gelijk, maar toch is er wel aan dat soort systemen gewerkt, specifiek voor de opslag van data die weinig verandert. Het heet Content Addressable Storage.Waar je om vraagt betekent dat elke logregel die je in /var/log/messages erbij schrijft betekent dat de hele file gelezen moet worden om de (nieuwe) hash te berekenen.
https://en.wikipedia.org/wiki/Content-addressable_storage
Door Anoniem:
Je weet dat je een file op een willekeurige plek kunt beschrijven, eraan kunt appenden , en files van enorme grootte kunt aanmaken zonder direct die hele file te schrijven [sparse file] ?
Waar je om vraagt betekent dat elke logregel die je in /var/log/messages erbij schrijft betekent dat de hele file gelezen moet worden om de (nieuwe) hash te berekenen.
Idem voor de heel grote files (feitelijk storage containers) waaruit een database is opgebouwd.
Dus nee, Niet Handig om elke schrijfactie te laten leiden tot het volledig lezen van de file die beschreven wordt.
Door Anoniem:
[..]
was er nu maar een file systeem die bij het aanmaken of veranderen van een file meteen een hash van de data en meta data bijhoudt. als i het maar om corruptie te detekteren, je zou die hashes meteen kunnen gebruiken voor een tool zoals TS zoekt.
[..]
was er nu maar een file systeem die bij het aanmaken of veranderen van een file meteen een hash van de data en meta data bijhoudt. als i het maar om corruptie te detekteren, je zou die hashes meteen kunnen gebruiken voor een tool zoals TS zoekt.
Je weet dat je een file op een willekeurige plek kunt beschrijven, eraan kunt appenden , en files van enorme grootte kunt aanmaken zonder direct die hele file te schrijven [sparse file] ?
Waar je om vraagt betekent dat elke logregel die je in /var/log/messages erbij schrijft betekent dat de hele file gelezen moet worden om de (nieuwe) hash te berekenen.
Idem voor de heel grote files (feitelijk storage containers) waaruit een database is opgebouwd.
Dus nee, Niet Handig om elke schrijfactie te laten leiden tot het volledig lezen van de file die beschreven wordt.
ho ho niet zo vlug:
als een file aangepast wordt, dan worden er uitteindelijk blokken op de disk veranderd. zfs bijv houdt al een hash van data blokken bij. je kunt dus per file de hashes van de data bloken tesamen hashen met een xor en dat als file meta data in de directory structuur opslaan. als nu een data blok verandert, xor je de oude totale hash eerst met de hash van het data blok voordat het verandert en daarna xor je met de hash van het nieuwe data blok en zo krijg je een nieuwe de totale xor van de blok hashes. dit kost je dus per blok een extra read naast de write. je hebt wel on the fly hashes van alle files meteen. het appenden van data kan sneller opgelost worden door hashes van lege blokken ook een lege hash (0-en) te definieren. Scheelt gedoe met sparse files en het appenden is eenvoudig data blokken schrijven en meteeen hashes van de data bloken xoren met de totale has weer. kortom, er zijn wel degelijk wat dingen die je zou kunnen doen.
Door Anoniem: Amateurs, ik druk op mijn Appeltje en typ wat ik zoek. ;)
ja ja maar vind je het ook :P
Door Anoniem:
ho ho niet zo vlug:
als een file aangepast wordt, dan worden er uitteindelijk blokken op de disk veranderd. zfs bijv houdt al een hash van data blokken bij. je kunt dus per file de hashes van de data bloken tesamen hashen met een xor en dat als file meta data in de directory structuur opslaan. als nu een data blok verandert, xor je de oude totale hash eerst met de hash van het data blok voordat het verandert en daarna xor je met de hash van het nieuwe data blok en zo krijg je een nieuwe de totale xor van de blok hashes. dit kost je dus per blok een extra read naast de write. je hebt wel on the fly hashes van alle files meteen. het appenden van data kan sneller opgelost worden door hashes van lege blokken ook een lege hash (0-en) te definieren. Scheelt gedoe met sparse files en het appenden is eenvoudig data blokken schrijven en meteeen hashes van de data bloken xoren met de totale has weer. kortom, er zijn wel degelijk wat dingen die je zou kunnen doen.
Door Anoniem:
Je weet dat je een file op een willekeurige plek kunt beschrijven, eraan kunt appenden , en files van enorme grootte kunt aanmaken zonder direct die hele file te schrijven [sparse file] ?
Waar je om vraagt betekent dat elke logregel die je in /var/log/messages erbij schrijft betekent dat de hele file gelezen moet worden om de (nieuwe) hash te berekenen.
Idem voor de heel grote files (feitelijk storage containers) waaruit een database is opgebouwd.
Dus nee, Niet Handig om elke schrijfactie te laten leiden tot het volledig lezen van de file die beschreven wordt.
Door Anoniem:
[..]
was er nu maar een file systeem die bij het aanmaken of veranderen van een file meteen een hash van de data en meta data bijhoudt. als i het maar om corruptie te detekteren, je zou die hashes meteen kunnen gebruiken voor een tool zoals TS zoekt.
[..]
was er nu maar een file systeem die bij het aanmaken of veranderen van een file meteen een hash van de data en meta data bijhoudt. als i het maar om corruptie te detekteren, je zou die hashes meteen kunnen gebruiken voor een tool zoals TS zoekt.
Je weet dat je een file op een willekeurige plek kunt beschrijven, eraan kunt appenden , en files van enorme grootte kunt aanmaken zonder direct die hele file te schrijven [sparse file] ?
Waar je om vraagt betekent dat elke logregel die je in /var/log/messages erbij schrijft betekent dat de hele file gelezen moet worden om de (nieuwe) hash te berekenen.
Idem voor de heel grote files (feitelijk storage containers) waaruit een database is opgebouwd.
Dus nee, Niet Handig om elke schrijfactie te laten leiden tot het volledig lezen van de file die beschreven wordt.
ho ho niet zo vlug:
als een file aangepast wordt, dan worden er uitteindelijk blokken op de disk veranderd. zfs bijv houdt al een hash van data blokken bij. je kunt dus per file de hashes van de data bloken tesamen hashen met een xor en dat als file meta data in de directory structuur opslaan. als nu een data blok verandert, xor je de oude totale hash eerst met de hash van het data blok voordat het verandert en daarna xor je met de hash van het nieuwe data blok en zo krijg je een nieuwe de totale xor van de blok hashes. dit kost je dus per blok een extra read naast de write. je hebt wel on the fly hashes van alle files meteen. het appenden van data kan sneller opgelost worden door hashes van lege blokken ook een lege hash (0-en) te definieren. Scheelt gedoe met sparse files en het appenden is eenvoudig data blokken schrijven en meteeen hashes van de data bloken xoren met de totale has weer. kortom, er zijn wel degelijk wat dingen die je zou kunnen doen.
On the fly crypto uit je mouw schudden is gevaarlijk.
Je zegt , als ik het goed begrijp , voor een file van twee blokken :
XOR (SHA Block 1) (SHA Block 2 )
Het resultaat van
XOR (SHA Block 2) (SHA Block 1) is precies hetzelfde.
Maar een file waarvan het tweede blok verwisseld is met het eerste blok is zeker niet identiek.
Dit voorbeeld is nog wel te repareren.
Een hash over een _hele_ file kun je niet 'snel' maken wanneer je ergens onderweg iets veranderd , je moet 'm dan weer helemaal maken. Omdat de hash waarde - dat is de eis voor een crypto hash - feitelijk door elke bit in de file beinvloed wordt.
Kun je iets hash-achtigs verzinnen waarbij je blokken van een file kunt herschrijven , en op een efficiente manier (zonder de hele file opnieuw te lezen) weer een robuuste fingerprint - ik weet niet of je het hash moet noemen - van de file maakt .
Waarschijnlijk wel - er zijn allerlei storage systemen die 'deduplicatie' beloven , als files, of grote delen van files identiek zijn.
Maar je betaalt hoe dan ook een forse prijs qua performance als elke schrijf actie leidt tot een vrij zware meta-data update actie.
(natte vinger : 32 bytes hash per blok van 1Kb -> 32 MByte metadata per GB file. Dat is een heel forse overhead. Het lezen/processen/terugschrijven van die metadata bij elke schrijfactie op de file zul je _dik_ terugzien in je IOPS .
Maak je de blokken waarvan je de hash neemt groter, dan wordt de metadata kleiner, maar de prijs is dat schrijfacties op grotere blokken werken - die gelezen moeten worden.)
No Free Lunch - indexen om sneller te zoeken (naar duplicaten, in dit geval) hebben een prijs.
Ik kan me voorstellen dat die prijs acceptabel is in sommige soorten opslag (iets als een document management systeem, misschien een backup storage omgeving), maar in een general purpose filesysteem zie ik het niet zitten.
Door Anoniem:
En die md5-waarde plak je dan gewoon achter de originele bestandsnaam.
Als dit met alle bestanden is gebeurt, kan je daarna met de normale search-manier zoeken of een bepaalde hashwaarde
vaker in een bestandsnaam voorkomt.
Tegelijk is het meteen ook een integriteitscontrole: na kopiëren, backup/restore e.d. moeten de hashwaarden in de bestandsnamen altijd kloppen met de daadwerkelijke hash van elk bestand.
Een addertje is nog wel dat soms een md5-collission optreedt met als resultaat een false positive.
Deze kans is geringer door een sterkere hash te gebruiken. (bijv. SHA1, 2 of 3)
Door Anoniem: Je moet 1x alle bestanden op je systeem indexeren en de md5 hash opslaan.
Vervolgens moet je een applicatie maken die checkt op md5 hash. Zo simpel is het
Vervolgens moet je een applicatie maken die checkt op md5 hash. Zo simpel is het
En die md5-waarde plak je dan gewoon achter de originele bestandsnaam.
Als dit met alle bestanden is gebeurt, kan je daarna met de normale search-manier zoeken of een bepaalde hashwaarde
vaker in een bestandsnaam voorkomt.
Tegelijk is het meteen ook een integriteitscontrole: na kopiëren, backup/restore e.d. moeten de hashwaarden in de bestandsnamen altijd kloppen met de daadwerkelijke hash van elk bestand.
Een addertje is nog wel dat soms een md5-collission optreedt met als resultaat een false positive.
Deze kans is geringer door een sterkere hash te gebruiken. (bijv. SHA1, 2 of 3)
Goede methode. Zelf gebruik ik CRC32 omdat anders de bestandsnamen zo lang worden.
WinRAR is behalve een goede archiver ook een prima tool om de CRC's te tonen. (geen idee hoe ik md5 of andere hashes zou moeten bekijken) Ook kun je met WinRAR een lijst maken van bestanden met daarnaast de CRC32, scheelt toch een hoop type-werk. Lange hashes vind ik toch een beetje onhandig, even snel kijken of 2 bestanden hetzelfde zijn gaat met 8 karakters toch wat makkelijker.
Door Anoniem:
Ik heb de programmeertaal Python nogal onderschat als ik dit zo bekijk. Misschien toch maar eens gaan leren.
Dat soort onderschatting zie ik opvallend vaak, met name onder mensen die een bloedhekel aan Python hebben en kankeren over wat er in hun ogen allemaal mis mee is. Mij valt dan altijd op dat ze a) Python niet meer dan heel oppervlakkig kennen, ze hebben er amper aan geroken;Schuldig vrees ik...
Door Anoniem: en b) denken dat hoe ze gewend zijn dat iets in de taal of talen die ze gewend zijn werkt, en in tools die op die talen gericht zijn, de enig mogelijke juiste manier is: wat ze kennen is hoe het hoort en wat daarvan afwijkt moet kennelijk bestreden worden.
Onschuldig; nou ja, misschien anders schuldig:
deps.edn
;; /deps.edn
{:deps {digest {:mvn/version "1.4.9"}}}
{:deps {digest {:mvn/version "1.4.9"}}}
fidufi
#! /usr/bin/env clojure
(ns fidufi
"Find duplicate files in the tree under specified pathname(s)."
(:require [clojure.java.io :refer [as-file]]
[digest :as digest])
(:import [java.io File]
[java.security MessageDigest]))
(defn md5sum
"Calculates md5sum for file."
[f]
(when (.exists f)
(let [pathName (.getPath f)]
(try [pathName (digest/md5 (as-file pathName))]
(catch Exception e (str "caught exception: " (.getMessage e)))))))
(defn partition-filter [p]
(filter (fn [e]
(let [a (first e)
b (second e)]
(= (second a) (second b))))
p))
(defn get-filtered-sizes
"Gets the file sizes filtered for equal sizes."
[files]
(let [file-sizes (map (fn [f] [ f (.length f)]) files)
sorted-by-sizes (sort-by second file-sizes)
partitioned-sizes (partition 2 1
[[]]
sorted-by-sizes)]
(partition-filter partitioned-sizes)))
(defn get-filtered-md5sums
"Gets the md5sums filtered for equal md5sums."
[filtered-sizes]
(let [md5sums (dedupe (reduce (fn [a b]
(conj a
(md5sum (first (first b)))
(md5sum (first (second b)))))
[]
filtered-sizes))
sorted-by-md5sums (sort-by second md5sums)
partitioned-md5sums (partition 2 1
[[]]
sorted-by-md5sums)]
(partition-filter partitioned-md5sums)))
(defn prepare-results
"Prepares results for blockwise output."
[filtered-md5sums]
(let [results (reduce (fn [a b]
(conj a (first b) (second b)))
[]
filtered-md5sums)]
(partition-by #(second %) results)))
(defn find-duplicates
"Finds duplicate files under specified pathname(s)."
[path]
(let [predfn (fn [p]
(or (not (.exists p))
(.isDirectory p)
(java.nio.file.Files/isSymbolicLink (.toPath p))))
files (remove predfn
(file-seq (File. path)))
filtered-sizes (get-filtered-sizes files)
filtered-md5sums (get-filtered-md5sums filtered-sizes)
results (prepare-results filtered-md5sums)]
(doseq [resultblock results]
(doseq [result (dedupe resultblock)]
(println (first result)))
(println))))
(if (empty? *command-line-args*)
(println "Usage: fidufi pathname")
(doseq [arg *command-line-args*] (find-duplicates arg)))
(ns fidufi
"Find duplicate files in the tree under specified pathname(s)."
(:require [clojure.java.io :refer [as-file]]
[digest :as digest])
(:import [java.io File]
[java.security MessageDigest]))
(defn md5sum
"Calculates md5sum for file."
[f]
(when (.exists f)
(let [pathName (.getPath f)]
(try [pathName (digest/md5 (as-file pathName))]
(catch Exception e (str "caught exception: " (.getMessage e)))))))
(defn partition-filter [p]
(filter (fn [e]
(let [a (first e)
b (second e)]
(= (second a) (second b))))
p))
(defn get-filtered-sizes
"Gets the file sizes filtered for equal sizes."
[files]
(let [file-sizes (map (fn [f] [ f (.length f)]) files)
sorted-by-sizes (sort-by second file-sizes)
partitioned-sizes (partition 2 1
[[]]
sorted-by-sizes)]
(partition-filter partitioned-sizes)))
(defn get-filtered-md5sums
"Gets the md5sums filtered for equal md5sums."
[filtered-sizes]
(let [md5sums (dedupe (reduce (fn [a b]
(conj a
(md5sum (first (first b)))
(md5sum (first (second b)))))
[]
filtered-sizes))
sorted-by-md5sums (sort-by second md5sums)
partitioned-md5sums (partition 2 1
[[]]
sorted-by-md5sums)]
(partition-filter partitioned-md5sums)))
(defn prepare-results
"Prepares results for blockwise output."
[filtered-md5sums]
(let [results (reduce (fn [a b]
(conj a (first b) (second b)))
[]
filtered-md5sums)]
(partition-by #(second %) results)))
(defn find-duplicates
"Finds duplicate files under specified pathname(s)."
[path]
(let [predfn (fn [p]
(or (not (.exists p))
(.isDirectory p)
(java.nio.file.Files/isSymbolicLink (.toPath p))))
files (remove predfn
(file-seq (File. path)))
filtered-sizes (get-filtered-sizes files)
filtered-md5sums (get-filtered-md5sums filtered-sizes)
results (prepare-results filtered-md5sums)]
(doseq [resultblock results]
(doseq [result (dedupe resultblock)]
(println (first result)))
(println))))
(if (empty? *command-line-args*)
(println "Usage: fidufi pathname")
(doseq [arg *command-line-args*] (find-duplicates arg)))
Disclaimer: garantie tot de deur; snel en lomp in elkaar gehackt; geen enkele poging tot optimalisatie, etc. "Crude, but effective".
Door Anoniem: Rare jongens, die programmeurs ;-)
Dat zeker! ;-)
Door Anoniem: ho ho niet zo vlug:
als een file aangepast wordt, dan worden er uitteindelijk blokken op de disk veranderd. zfs bijv houdt al een hash van data blokken bij. je kunt dus per file de hashes van de data bloken tesamen hashen met een xor en dat als file meta data in de directory structuur opslaan. als nu een data blok verandert, xor je de oude totale hash eerst met de hash van het data blok voordat het verandert en daarna xor je met de hash van het nieuwe data blok en zo krijg je een nieuwe de totale xor van de blok hashes. dit kost je dus per blok een extra read naast de write. je hebt wel on the fly hashes van alle files meteen. het appenden van data kan sneller opgelost worden door hashes van lege blokken ook een lege hash (0-en) te definieren. Scheelt gedoe met sparse files en het appenden is eenvoudig data blokken schrijven en meteeen hashes van de data bloken xoren met de totale has weer. kortom, er zijn wel degelijk wat dingen die je zou kunnen doen.
Ik denk niet dat dit 100% waterdicht is, althans niet als mijn beperkte inzicht in ZFS klopt.als een file aangepast wordt, dan worden er uitteindelijk blokken op de disk veranderd. zfs bijv houdt al een hash van data blokken bij. je kunt dus per file de hashes van de data bloken tesamen hashen met een xor en dat als file meta data in de directory structuur opslaan. als nu een data blok verandert, xor je de oude totale hash eerst met de hash van het data blok voordat het verandert en daarna xor je met de hash van het nieuwe data blok en zo krijg je een nieuwe de totale xor van de blok hashes. dit kost je dus per blok een extra read naast de write. je hebt wel on the fly hashes van alle files meteen. het appenden van data kan sneller opgelost worden door hashes van lege blokken ook een lege hash (0-en) te definieren. Scheelt gedoe met sparse files en het appenden is eenvoudig data blokken schrijven en meteeen hashes van de data bloken xoren met de totale has weer. kortom, er zijn wel degelijk wat dingen die je zou kunnen doen.
Voor zover ik het begrijp hanteert ZFS een variabele bloklengte die een veelvoud is van een kleinere blokgrootte. De checksum wordt over die grotere blokken berekend, waarbij mij niet duidelijk is of dat (indien gebruikt) voor of na compressie is.
Stel nou dat je twee bestanden opbouwt met een identieke inhoud, maar dat in verschillende stappen doet. Het ene bestand schrijf je bijvoorbeeld als 2x de helft van de inhoud, het andere bestand als 3x een derde van de inhoud, en in beide gevallen open en sluit je het bestand voor en na het schrijven van elk deel.
Dan heb je twee bestanden met identieke inhoud, waarvan de een als twee en de ander als drie blokken is opgeslagen, en elk van die 5 blokken heeft een andere inhoud en dus een andere checksum (het kunnen meer dan 5 blokken worden als de maximale blokgrootte wordt overschreden, en dat kan weer identieke blokken opleveren, maar die mogelijkheid compliceert het beeld zonder de conclusie te veranderen, dus houd ik het bij 2+3=5 blokken).
Als hash gebruikt ZFS default fletcher of als deduplicatie actief is sha256. Voor beide hashes geldt niet dat je ze simpelweg met XOR of op een andere manier kan combineren zodanig dat die 2 hashes uit het ene bestand en die 3 uit het andere dezelfde eindwaarde opleveren.
Als dit allemaal klopt dan is het mogelijk om op ZFS twee identieke bestanden te construeren waarvan de hashes zoals jij ze voorstelt een verschillende waarde hebben. Dan is het geen waterdichte basis op om identieke bestanden te vinden.
Ik denk trouwens dat er sowieso wel redenen zijn om dit soort functies te implementeren op een manier die niet aan een specifiek filesysteem gebonden is. Niet iedereen gebruikt ZFS, zoekacties naar kopieën kunnen zich over meerdere filesystemen uitstrekken, noem maar op. En als deduplicatie om schijfruimte te besparen je doel is: dat kan ZFS zelf al.
Door Krakatau:
Onschuldig; nou ja, misschien anders schuldig:
[knip clojure]
Heerlijk, dank! :-)Onschuldig; nou ja, misschien anders schuldig:
[knip clojure]
Door Anoniem:
Door Krakatau:
Onschuldig; nou ja, misschien anders schuldig:
[knip clojure]
Heerlijk, dank! :-)Onschuldig; nou ja, misschien anders schuldig:
[knip clojure]
Idem :-) Ik zie trouwens wel een verschil in de resultaten: bestanden met grootte 0. Oh, dat is met opzet zie ik- path.stat().st_size != 0 - en natuurlijk wel zo logisch.
...
(:require [clojure.java.io :refer [as-file] :as io]
...
predfn (fn [p]
(or (not (.exists p))
(.isDirectory p)
(= (.length (io/file p)) 0)
(java.nio.file.Files/isSymbolicLink (.toPath p)
(:require [clojure.java.io :refer [as-file] :as io]
...
predfn (fn [p]
(or (not (.exists p))
(.isDirectory p)
(= (.length (io/file p)) 0)
(java.nio.file.Files/isSymbolicLink (.toPath p)
Door Krakatau:
Dat zeker! ;-)
Door Anoniem: Rare jongens, die programmeurs ;-)
Dat zeker! ;-)
Ik wist niet dat Kratatau bij de laatste grote eruptie in 1883 ook het Lisp mineraal met de asregens over Java uitstortte.
25-02-2020, 13:08 door
The FOSS
Snake coders!
Python is the “v2/v3” double barrel shotgun, only one barrel will shoot at a time, and you never end up shooting the recommended one. [*].
Héé Kraak! Je weet het hè: Lisp is a shiv which comes in many forms. Anyone who uses this is probably crazy and dangerous. [*].
(P.S. Ik ben al jaren een groot fan! Mijn eerdere nicknames zijn me vergeven hoop ik? Bedenk: imitation is the sincerest form of flattery.).
[*] https://hippocreative.com.au/if-programming-languages-were-weapons/
Door Anoniem:
Python code section
Python is the “v2/v3” double barrel shotgun, only one barrel will shoot at a time, and you never end up shooting the recommended one. [*].
Door Krakatau:
Lispy code section
Héé Kraak! Je weet het hè: Lisp is a shiv which comes in many forms. Anyone who uses this is probably crazy and dangerous. [*].
(P.S. Ik ben al jaren een groot fan! Mijn eerdere nicknames zijn me vergeven hoop ik? Bedenk: imitation is the sincerest form of flattery.).
[*] https://hippocreative.com.au/if-programming-languages-were-weapons/
Door Anoniem:
Voor zover ik het begrijp hanteert ZFS een variabele bloklengte die een veelvoud is van een kleinere blokgrootte. De checksum wordt over die grotere blokken berekend, waarbij mij niet duidelijk is of dat (indien gebruikt) voor of na compressie is.
Stel nou dat je twee bestanden opbouwt met een identieke inhoud, maar dat in verschillende stappen doet. Het ene bestand schrijf je bijvoorbeeld als 2x de helft van de inhoud, het andere bestand als 3x een derde van de inhoud, en in beide gevallen open en sluit je het bestand voor en na het schrijven van elk deel.
Dan heb je twee bestanden met identieke inhoud, waarvan de een als twee en de ander als drie blokken is opgeslagen, en elk van die 5 blokken heeft een andere inhoud en dus een andere checksum (het kunnen meer dan 5 blokken worden als de maximale blokgrootte wordt overschreden, en dat kan weer identieke blokken opleveren, maar die mogelijkheid compliceert het beeld zonder de conclusie te veranderen, dus houd ik het bij 2+3=5 blokken).
Als hash gebruikt ZFS default fletcher of als deduplicatie actief is sha256. Voor beide hashes geldt niet dat je ze simpelweg met XOR of op een andere manier kan combineren zodanig dat die 2 hashes uit het ene bestand en die 3 uit het andere dezelfde eindwaarde opleveren.
Als dit allemaal klopt dan is het mogelijk om op ZFS twee identieke bestanden te construeren waarvan de hashes zoals jij ze voorstelt een verschillende waarde hebben. Dan is het geen waterdichte basis op om identieke bestanden te vinden.
Ik denk trouwens dat er sowieso wel redenen zijn om dit soort functies te implementeren op een manier die niet aan een specifiek filesysteem gebonden is. Niet iedereen gebruikt ZFS, zoekacties naar kopieën kunnen zich over meerdere filesystemen uitstrekken, noem maar op. En als deduplicatie om schijfruimte te besparen je doel is: dat kan ZFS zelf al.
Door Anoniem: ho ho niet zo vlug:
als een file aangepast wordt, dan worden er uitteindelijk blokken op de disk veranderd. zfs bijv houdt al een hash van data blokken bij. je kunt dus per file de hashes van de data bloken tesamen hashen met een xor en dat als file meta data in de directory structuur opslaan. als nu een data blok verandert, xor je de oude totale hash eerst met de hash van het data blok voordat het verandert en daarna xor je met de hash van het nieuwe data blok en zo krijg je een nieuwe de totale xor van de blok hashes. dit kost je dus per blok een extra read naast de write. je hebt wel on the fly hashes van alle files meteen. het appenden van data kan sneller opgelost worden door hashes van lege blokken ook een lege hash (0-en) te definieren. Scheelt gedoe met sparse files en het appenden is eenvoudig data blokken schrijven en meteeen hashes van de data bloken xoren met de totale has weer. kortom, er zijn wel degelijk wat dingen die je zou kunnen doen.
Ik denk niet dat dit 100% waterdicht is, althans niet als mijn beperkte inzicht in ZFS klopt.als een file aangepast wordt, dan worden er uitteindelijk blokken op de disk veranderd. zfs bijv houdt al een hash van data blokken bij. je kunt dus per file de hashes van de data bloken tesamen hashen met een xor en dat als file meta data in de directory structuur opslaan. als nu een data blok verandert, xor je de oude totale hash eerst met de hash van het data blok voordat het verandert en daarna xor je met de hash van het nieuwe data blok en zo krijg je een nieuwe de totale xor van de blok hashes. dit kost je dus per blok een extra read naast de write. je hebt wel on the fly hashes van alle files meteen. het appenden van data kan sneller opgelost worden door hashes van lege blokken ook een lege hash (0-en) te definieren. Scheelt gedoe met sparse files en het appenden is eenvoudig data blokken schrijven en meteeen hashes van de data bloken xoren met de totale has weer. kortom, er zijn wel degelijk wat dingen die je zou kunnen doen.
Voor zover ik het begrijp hanteert ZFS een variabele bloklengte die een veelvoud is van een kleinere blokgrootte. De checksum wordt over die grotere blokken berekend, waarbij mij niet duidelijk is of dat (indien gebruikt) voor of na compressie is.
Stel nou dat je twee bestanden opbouwt met een identieke inhoud, maar dat in verschillende stappen doet. Het ene bestand schrijf je bijvoorbeeld als 2x de helft van de inhoud, het andere bestand als 3x een derde van de inhoud, en in beide gevallen open en sluit je het bestand voor en na het schrijven van elk deel.
Dan heb je twee bestanden met identieke inhoud, waarvan de een als twee en de ander als drie blokken is opgeslagen, en elk van die 5 blokken heeft een andere inhoud en dus een andere checksum (het kunnen meer dan 5 blokken worden als de maximale blokgrootte wordt overschreden, en dat kan weer identieke blokken opleveren, maar die mogelijkheid compliceert het beeld zonder de conclusie te veranderen, dus houd ik het bij 2+3=5 blokken).
Als hash gebruikt ZFS default fletcher of als deduplicatie actief is sha256. Voor beide hashes geldt niet dat je ze simpelweg met XOR of op een andere manier kan combineren zodanig dat die 2 hashes uit het ene bestand en die 3 uit het andere dezelfde eindwaarde opleveren.
Als dit allemaal klopt dan is het mogelijk om op ZFS twee identieke bestanden te construeren waarvan de hashes zoals jij ze voorstelt een verschillende waarde hebben. Dan is het geen waterdichte basis op om identieke bestanden te vinden.
Ik denk trouwens dat er sowieso wel redenen zijn om dit soort functies te implementeren op een manier die niet aan een specifiek filesysteem gebonden is. Niet iedereen gebruikt ZFS, zoekacties naar kopieën kunnen zich over meerdere filesystemen uitstrekken, noem maar op. En als deduplicatie om schijfruimte te besparen je doel is: dat kan ZFS zelf al.
waterdicht?
neen, maar wel een ontzettende versnelling: als twee hashes niet identiek zijn => files niet idendiek, negeer ze maar. twee hashes hetzelfde? dan moet je gedetaileerder kijken.
Door Anoniem: waterdicht?
neen, maar wel een ontzettende versnelling: als twee hashes niet identiek zijn => files niet idendiek, negeer ze maar. twee hashes hetzelfde? dan moet je gedetaileerder kijken.
Ik gaf een voorbeeld van hoe twee identieke files verschillende hashes kunnen hebben volgens jouw(?) methode. Dan gaat "twee hashes niet identiek => files niet identiek" niet op en is "twee hashes niet identiek => files toch identiek" ook mogelijk. Als je dat wilt uitsluiten moet je opeens alles gedetailleerder bekijken en heb je niets meer aan die ZFS-checksums.neen, maar wel een ontzettende versnelling: als twee hashes niet identiek zijn => files niet idendiek, negeer ze maar. twee hashes hetzelfde? dan moet je gedetaileerder kijken.
Door Anoniem:
Door Anoniem: waterdicht?
neen, maar wel een ontzettende versnelling: als twee hashes niet identiek zijn => files niet idendiek, negeer ze maar. twee hashes hetzelfde? dan moet je gedetaileerder kijken.
Ik gaf een voorbeeld van hoe twee identieke files verschillende hashes kunnen hebben volgens jouw(?) methode. Dan gaat "twee hashes niet identiek => files niet identiek" niet op en is "twee hashes niet identiek => files toch identiek" ook mogelijk. Als je dat wilt uitsluiten moet je opeens alles gedetailleerder bekijken en heb je niets meer aan die ZFS-checksums.neen, maar wel een ontzettende versnelling: als twee hashes niet identiek zijn => files niet idendiek, negeer ze maar. twee hashes hetzelfde? dan moet je gedetaileerder kijken.
ah niet goed gelezen, zat met vaste blok sizes in mijn gedachten en dan werkt het wel wat ik bedoel. als je variabele blok sizes hebt dan bestaat er inderdaad de mogelijkheid dat twee identieke file vwb inhoud een andere hash geven. heb je echter vaste (basis) blokken, dan kan dat weer niet.
maargoed, het princiepe hoeft niet persee met zfs en variabele blokken gedaan worden, er kan ook specifiek een fs gemaakt worden. wellicht kan zoiets gedaan worden via een dm device in linux dat zodra het een blok te schrijven krijgt een hash uitrekend, de blok op disk zet met daarbij de hash op het onderligende device. het dm device kan die hash gebruiken om de read integriteit te bewaken van disk. een fs daarbovenop dat dm device kan die blok hashes van een file weer tezamen xoren tot een file hash. alles natuurlijk met voorwaarde dat blokken van vaste grote in de dm device gebruikt worden.
25-02-2020, 21:20 door
Krakatau
@The FOSS
Lispelend als een slang op de JVM.
Er is een hele waslijst aan JVM-based languages: https://en.wikipedia.org/wiki/List_of_JVM_languages
Lispelend als een slang op de JVM.
Door Anoniem:
Ik wist niet dat Kratatau bij de laatste grote eruptie in 1883 ook het Lisp mineraal met de asregens over Java uitstortte.
Door Krakatau:
Dat zeker! ;-)
Door Anoniem: Rare jongens, die programmeurs ;-)
Dat zeker! ;-)
Ik wist niet dat Kratatau bij de laatste grote eruptie in 1883 ook het Lisp mineraal met de asregens over Java uitstortte.
Er is een hele waslijst aan JVM-based languages: https://en.wikipedia.org/wiki/List_of_JVM_languages
06-04-2020, 18:35 door
Krakatau
06-04-2020, 21:33 door
souplost
Zie ook https://neatdecisions.com/products/
25-10-2020, 10:48 door
Krakatau
Door Anoniem:
#!/usr/bin/env python3
...
...
Python draait zelfs op je Android telefoon onder Termux. Jouw programma ook! Gaaf dat Python op zoveel platforms volwaardig is te gebruiken!
Door Krakatau:
Python draait zelfs op je Android telefoon onder Termux. Jouw programma ook! Gaaf dat Python op zoveel platforms volwaardig is te gebruiken!
Leuk om te horen :-)Door Anoniem:
#!/usr/bin/env python3
...
...
Python draait zelfs op je Android telefoon onder Termux. Jouw programma ook! Gaaf dat Python op zoveel platforms volwaardig is te gebruiken!
25-10-2020, 22:40 door
Krakatau
Door Anoniem:
Door Krakatau:
Python draait zelfs op je Android telefoon onder Termux. Jouw programma ook! Gaaf dat Python op zoveel platforms volwaardig is te gebruiken!
Leuk om te horen :-)Door Anoniem:
#!/usr/bin/env python3
...
...
Python draait zelfs op je Android telefoon onder Termux. Jouw programma ook! Gaaf dat Python op zoveel platforms volwaardig is te gebruiken!
Ik ben gestart met een Python bootcamp :-)
https://youtu.be/rfscVS0vtbw
Met de DCMA takedown van het Python based youtube-dl vond ik het hoog tijd worden.
org 0
ld sp, stack_start
monitor:
ld a, '>'
out (1),a
ld hl, input_buffer
monitor_input_loop:
ld (hl), '\n'
in a,(1)
ld (hl),a
cp '\n'
jr z, process_input_line
inc hl
jr monitor_input_loop
process_input_line:
ld hl, input_buffer
ld a, (hl)
cp 'c'
jr z, call_handler
cp 'C'
jr z, call_handler
cp 'd'
jr z, dump_handler
cp 'D'
jr z, dump_handler
cp 'i'
jr z, input_handler
cp 'I'
jr z, input_handler
ld a, 'E'
out (1),a
ld a, 'R'
out (1), a
out (1), a
ld a, '\n'
out (1),a
jr monitor
call_handler:
ld hl, input_buffer+1
call read_16_bit_ascii_number
ld hl,monitor
push hl
push bc
ret
dump_handler:
ld hl, input_buffer+1
ld a, (hl)
cp '\n'
jr z, dump_handler_no_number
call read_16_bit_ascii_number
ld (dump_address), bc
dump_handler_no_number:
ld hl, (dump_address)
call output_16_bit_number
ld b, 16
dump_byte:
ld a, ' '
out (1), a
ld c, (hl)
call output_8_bit_number
inc hl
djnz dump_byte
ld a, '\n'
out (1),a
ld (dump_address), hl
jmp_monitor:
jr monitor
input_handler:
ld hl, input_buffer+1
ld a, (hl)
cp ' '
jr z, input_handler_no_address
call read_16_bit_ascii_number
ld (input_address), bc
input_handler_no_address:
ld a,(hl)
inc hl
cp ' '
jr z, input_handler_no_address
cp '\n'
jr z, jmp_monitor
dec hl
call read_8_bit_ascii_number
ld bc, (input_address)
ld (bc), a
inc bc
ld (input_address), bc
jr input_handler_no_address
read_16_bit_ascii_number:
call read_8_bit_ascii_number
ld b, a
call read_8_bit_ascii_number
ld c, a
ret
read_8_bit_ascii_number:
ld a, (hl)
cp 'a'
jr c, read_8_bit_ascii_number_uc
cp 'z'
jr nc, read_8_bit_ascii_number_uc
sub a, 32
read_8_bit_ascii_number_uc:
call read_8_bit_ascii_number_hex
add a, a
add a, a
add a, a
add a, a
ld d, a
inc hl
ld a, (hl)
call read_8_bit_ascii_number_hex
or d
inc hl
ret
read_8_bit_ascii_number_hex:
sub a, '0'
cp 10
ret c
sub a,'A'-'0'-10
ret
output_16_bit_number:
ld c,h
call output_8_bit_number
ld c,l
call output_8_bit_number
ret
output_8_bit_number:
ld a,c
rra
rra
rra
rra
call Conv
ld a,c
Conv:
and $0F
add a,$90
daa
adc a,$40
daa
out (1),a
ret
dump_address:
db 0,0
input_address:
db 0,0
stack_end:
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
stack_start:
input_buffer:
Door Anoniem:
org 0
ld sp, stack_start
monitor:
ld a, '>'
out (1),a
ld hl, input_buffer
monitor_input_loop:
ld (hl), '\n'
in a,(1)
ld (hl),a
cp '\n'
jr z, process_input_line
inc hl
jr monitor_input_loop
process_input_line:
ld hl, input_buffer
ld a, (hl)
cp 'c'
jr z, call_handler
cp 'C'
jr z, call_handler
cp 'd'
jr z, dump_handler
cp 'D'
jr z, dump_handler
cp 'i'
jr z, input_handler
cp 'I'
jr z, input_handler
ld a, 'E'
out (1),a
ld a, 'R'
out (1), a
out (1), a
ld a, '\n'
out (1),a
jr monitor
call_handler:
ld hl, input_buffer+1
call read_16_bit_ascii_number
ld hl,monitor
push hl
push bc
ret
dump_handler:
ld hl, input_buffer+1
ld a, (hl)
cp '\n'
jr z, dump_handler_no_number
call read_16_bit_ascii_number
ld (dump_address), bc
dump_handler_no_number:
ld hl, (dump_address)
call output_16_bit_number
ld b, 16
dump_byte:
ld a, ' '
out (1), a
ld c, (hl)
call output_8_bit_number
inc hl
djnz dump_byte
ld a, '\n'
out (1),a
ld (dump_address), hl
jmp_monitor:
jr monitor
input_handler:
ld hl, input_buffer+1
ld a, (hl)
cp ' '
jr z, input_handler_no_address
call read_16_bit_ascii_number
ld (input_address), bc
input_handler_no_address:
ld a,(hl)
inc hl
cp ' '
jr z, input_handler_no_address
cp '\n'
jr z, jmp_monitor
dec hl
call read_8_bit_ascii_number
ld bc, (input_address)
ld (bc), a
inc bc
ld (input_address), bc
jr input_handler_no_address
read_16_bit_ascii_number:
call read_8_bit_ascii_number
ld b, a
call read_8_bit_ascii_number
ld c, a
ret
read_8_bit_ascii_number:
ld a, (hl)
cp 'a'
jr c, read_8_bit_ascii_number_uc
cp 'z'
jr nc, read_8_bit_ascii_number_uc
sub a, 32
read_8_bit_ascii_number_uc:
call read_8_bit_ascii_number_hex
add a, a
add a, a
add a, a
add a, a
ld d, a
inc hl
ld a, (hl)
call read_8_bit_ascii_number_hex
or d
inc hl
ret
read_8_bit_ascii_number_hex:
sub a, '0'
cp 10
ret c
sub a,'A'-'0'-10
ret
output_16_bit_number:
ld c,h
call output_8_bit_number
ld c,l
call output_8_bit_number
ret
output_8_bit_number:
ld a,c
rra
rra
rra
rra
call Conv
ld a,c
Conv:
and $0F
add a,$90
daa
adc a,$40
daa
out (1),a
ret
dump_address:
db 0,0
input_address:
db 0,0
stack_end:
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
stack_start:
input_buffer:
org 0
ld sp, stack_start
monitor:
ld a, '>'
out (1),a
ld hl, input_buffer
monitor_input_loop:
ld (hl), '\n'
in a,(1)
ld (hl),a
cp '\n'
jr z, process_input_line
inc hl
jr monitor_input_loop
process_input_line:
ld hl, input_buffer
ld a, (hl)
cp 'c'
jr z, call_handler
cp 'C'
jr z, call_handler
cp 'd'
jr z, dump_handler
cp 'D'
jr z, dump_handler
cp 'i'
jr z, input_handler
cp 'I'
jr z, input_handler
ld a, 'E'
out (1),a
ld a, 'R'
out (1), a
out (1), a
ld a, '\n'
out (1),a
jr monitor
call_handler:
ld hl, input_buffer+1
call read_16_bit_ascii_number
ld hl,monitor
push hl
push bc
ret
dump_handler:
ld hl, input_buffer+1
ld a, (hl)
cp '\n'
jr z, dump_handler_no_number
call read_16_bit_ascii_number
ld (dump_address), bc
dump_handler_no_number:
ld hl, (dump_address)
call output_16_bit_number
ld b, 16
dump_byte:
ld a, ' '
out (1), a
ld c, (hl)
call output_8_bit_number
inc hl
djnz dump_byte
ld a, '\n'
out (1),a
ld (dump_address), hl
jmp_monitor:
jr monitor
input_handler:
ld hl, input_buffer+1
ld a, (hl)
cp ' '
jr z, input_handler_no_address
call read_16_bit_ascii_number
ld (input_address), bc
input_handler_no_address:
ld a,(hl)
inc hl
cp ' '
jr z, input_handler_no_address
cp '\n'
jr z, jmp_monitor
dec hl
call read_8_bit_ascii_number
ld bc, (input_address)
ld (bc), a
inc bc
ld (input_address), bc
jr input_handler_no_address
read_16_bit_ascii_number:
call read_8_bit_ascii_number
ld b, a
call read_8_bit_ascii_number
ld c, a
ret
read_8_bit_ascii_number:
ld a, (hl)
cp 'a'
jr c, read_8_bit_ascii_number_uc
cp 'z'
jr nc, read_8_bit_ascii_number_uc
sub a, 32
read_8_bit_ascii_number_uc:
call read_8_bit_ascii_number_hex
add a, a
add a, a
add a, a
add a, a
ld d, a
inc hl
ld a, (hl)
call read_8_bit_ascii_number_hex
or d
inc hl
ret
read_8_bit_ascii_number_hex:
sub a, '0'
cp 10
ret c
sub a,'A'-'0'-10
ret
output_16_bit_number:
ld c,h
call output_8_bit_number
ld c,l
call output_8_bit_number
ret
output_8_bit_number:
ld a,c
rra
rra
rra
rra
call Conv
ld a,c
Conv:
and $0F
add a,$90
daa
adc a,$40
daa
out (1),a
ret
dump_address:
db 0,0
input_address:
db 0,0
stack_end:
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
db 0, 0
stack_start:
input_buffer:
Wa is dè? Een stukje M$ Windows source code?
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Chief Information Security Officer
Utrecht heeft jou nodig! Als Chief Information Security Officer speel jij een cruciale rol in de bescherming van de digitale informatie van de gemeente Utrecht. Als geen ander weet jij welke dreigingen er zijn en kun je deze vertalen naar risico's die de gemeente en haar inwoners lopen. Solliciteer nu!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
