Zoeken in groot textbestand (40GB)

[Sando]

Hoi,

Ik zoek een tool waarmee ik kan zoeken en knippen in een groot textbestand. Groter dan mijn (computer's) geheugen.

Dat is alles. Maar voor nieuwschierigen hier wat meer info:

Mijn laptopschijf was helemaal naar de %$@# en ik heb over het algemeen wel een goede backup maar ik mis een bestandje.

De partitietabel was nog goed, maar de file table niet. Ik probeerde al chkdsk, norton disk doctor, ntfsdos, ntfs-3g onder linux, onTrack Data Recovery, tools van Hiren's boot CD en ik kan lange verhalen ophangen maar allemaal konden ze mijn partities of mijn bestandje niet terughalen. Uiteindelijk maar in linux met dd een image van de harde schijf gemaakt. Miljard jaar geleden deed ik dat wel eens met floppy's en kon ik in Windows met notepad achtige tools mijn zaken als rauwe text terugvinden.

Veel is verandert, zoals de grote van het image in vergelijking tot mijn geheugen, maar mijn document is gelukkig gewoon plain text zonder cryptfs oid. Dus als ik gewoon kan zoeken naar de titel in het image dan vind ik het ws wel.

Notepad, Notepad++, EdXor en heleboel tools die je anders nooit zou downloaden kunnen het niet openen, ookal zeggen ze dat ze onbeperkt grote bestanden kunnen openen. Het liefst heb ik een windows-truukje, maar als je een oplossing hebt voor in linux ben ik ook heel blij!

[pven]

Je kan proberen om het met grep te doorzoeken (ja, dat is er ook voor windows), maar ik weet niet of je daarmee een bestand van 40GB kan doorzoeken.

[Sando]

(nog niet geprobeert maar) grep werkt (iig in linux) volgens mij wel op dergelijk grote bestanden. Het werkte iig wel toen het bestand nog een harde schijf was. Probleem is dat ik dan niet zie waar de rest zit (op welke offset ik een plakje moet snijden), en even scrollen naar andere versies is er niet bij. (raar maar waar, soms blijken er bij elkaar in de buurt meerdere versies te staan, alsof 'ie' bij het opslaan steeds een nieuwe file schrijft.)

[Anoniem: 4629]

UltraEdit-32 kan ook vrij goed overweg met diskbased textfiles.

[DiSiLLUSiON]

Als het een direct image dump is, dan is het toch geen text bestand? Misschien eens kijken naar een binary tooltje?

-Edit: misschien kan je het bestand eerst opsplitsen in chunks van rond de 2gb, zodat de meeste hex editors (of misschien zelfs een text tool als Notepad++) deze wel kan lezen? Als je linux hebt kan dat geloof ik door middel van het 'head' commando.

[ Voor 56% gewijzigd door DiSiLLUSiON op 28-04-2008 05:38 ]

[Anoniem: 399]

Ik geloof dat je in pure theorie het bestandje met JuJuEdit wel zou kunnen doorzoeken (vorige week nog een file van 2.6 GB gedaan) alhoewel woorden als Performance, Efficiency, Stabiliteit en Gebruikgemak met zo'n enorme file vermoedelijk alleen in de ontkennende vorm aan je ervaring gekoppeld zouden worden.
De file opsplitsen is wel een 100x beter idee, omdat ik van die grootte file vermoed dat elke Windows editor klapt omdat ie meer dan de beschikbare 2 GB heugen probeert toe te wijzen (nou liep JuJuEdit niet vast bij 2.6 GB... )

[Tukk]

Anoniem: 4629 schreef op maandag 28 april 2008 @ 03:09:
UltraEdit-32 kan ook vrij goed overweg met diskbased textfiles.

Met Notepad++ als gratis alternatief op UEdit.

[Sando]

DiSiLLUSiON schreef op maandag 28 april 2008 @ 05:33:
Als het een direct image dump is, dan is het toch geen text bestand? Misschien eens kijken naar een binary tooltje?

Ja jee hebt gelijk, maar als je binary files gewoon opent met een text-editor zal je raw text gewoon terug kunnen lezen. Open je bootmanager (ntldr/bootmgr) maar eens met notepad, dan zie je dat alle mogelijke foutmeldingen ook gewoon raw zijn.

Anoniem: 4629 schreef op maandag 28 april 2008 @ 03:09:
UltraEdit-32 kan ook vrij goed overweg met diskbased textfiles.

Commerciële tools stel ik eventjes uit tot ik wanhopig wordt.

Anoniem: 399 schreef op maandag 28 april 2008 @ 15:27:
Ik geloof dat je in pure theorie het bestandje met JuJuEdit wel zou kunnen doorzoeken

Tx voor tip. Ik probeerde JujuEdit, maar meteen bij openen gaat ie al zeggen dat ie te groot is, > 2 gig mag niet. Apart dat jij die grens kon omzeilen.. ik heb wel genoeg geheugen (4G).

Tukk schreef op maandag 28 april 2008 @ 15:30:
Met Notepad++ als gratis alternatief op UEdit.

N++ gebruik ik al erg lang. Supertool, en daarom ook als eerste geprobeert. Maar na een minuutje crasht ie zonder iets te laden. Zie ik een optie over het hoofd of kan N++ helemaal geen disk based grote dingen laden?

[Sando]

Dat niet alles altijd goed gaat snap ik wel, zo zou het ook zijn als ik de wereld had gemaakt. Maar je kan ook overdrijven.

Eerst zocht ik een dik half uur naar een rechte grepkloon voor DOS/Windows, en ze waren allemaal net niet met opties die ik zocht. Je staat versteld van voor welke crap mensen geld durven te vragen. Daarna nog een paar lame GUI greptools geprobeert, allemaal niet werkende zoals ik wil.

De backup zit in mijn werkcomputer, en die kan ik niet naar Linux booten want hij is bezig met belangrijke zaken. Dan maar een netwerkshare gemaakt en via mijn laptop in Zenwalk geboot en met sambafuse de share gemount. grep dit en dat, no matches found. Ja dat geloof ik niet want hij deed er een paar seconden over.

Toen maar Ubuntu geboot op mijn werkcomputer via een virtuele machine, en de schijf met backup als 'letterlijke' schijf aan de vm toekennen. Bladiebladiebla, schijf leeg in Ubuntu. Ik schrok me de tering, maar toen ik de vm netjes afsloot was de schijf in windows gelukkig nog alsvanouds.

Nu heb ik de schijf gewoon uit mijn computer geschroeft (bij sata kan dat, mits ahci), in een externe behuizing gestopt en via usb met mijn andere linux-desktop verbonden en EINDELIJK lijkt het de goede kant op te gaan.

Dat wil zeggen dat ik een commando opgaf en dat ie al een kwartier bezig is. Na het bestuderen van de grep manpage deed ik zoiets als dit:

$ grep -U -b -B 100 -A 1000 -m 1 zoekterm ./sda.img > ./test.txt

Het maken van een image kostte ongeveer 30 - 60 minuten. Dat zoeken zal toch wel veel sneller gaan? Naja ik zal het dadelijk merken. Bedankt voor de tips in ieder geval!

[Sando]

Ik ben trouwens nu al dom, want -B 100 -A 1000 betekent dat ie 100 regels voor en 1000 regels na een match mee output. 10 (binair tellen) maal raden in wat voor bestanden alles op één regel staat...

Dan wacht ik maar ff wat ie er van bakt maar ik wilde teveel tegelijk. Met -U -b zou ie al een offset moeten geven en dan kon ik met head rond die offset gaan knippen. Als ik straks een test.txt van 40 GB heb zal ik het even op die andere manier proberen.

-update-

Nog een snufje eigen schuld erbij..
Grep vond niets, maar er zat ook een typo in de zoekterm. Bij verbetering zegt ie weer in 1 seconde dat er niets gevonden was. Cached' ie leugens ofzo? unmount/mount helpt niet, bestand verplaatsen niet.. reboot niet.. ik snap er niets meer van. Misschien heb ik te lang gecomputert vandaag

Zijn er andere truukjes? Undelete software voor raw images?

[ Voor 70% gewijzigd door Sando op 29-04-2008 02:01 ]