It is different now: [code] top - 11:47:22 up 35 days, 23:50, 3 users, load average: 5.84, 5.99, 6.03 Tasks: 252 total, 2 running, 248 sleeping, 2 stopped, 0 zombie %Cpu(s): 20.8 us, 3.1 sy, 0.0 ni, 33.7 id, 42.5 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 16385720 total, 719992 free, 856244 used, 14809484 buff/cache KiB Swap: 20971516 total, 20888104 free, 83412 used. 15429524 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4151 root 20 0 6420 164 76 S 25.2 0.0 61:06.20 srch_strings 4132 root 20 0 6420 168 84 R 23.5 0.0 64:40.62 srch_strings 10086 root 20 0 6420 88 0 S 20.5 0.0 1377:21 srch_strings 4171 root 20 0 6420 132 44 S 20.2 0.0 57:21.69 srch_strings 7944 root 20 0 6420 88 0 S 18.2 0.0 523:33.29 srch_strings 7945 root 20 0 6420 88 0 S 18.2 0.0 565:22.88 srch_strings 4131 root 20 0 29904 1144 768 S 3.6 0.0 9:06.74 blkls 4150 root 20 0 29904 1148 768 D 3.6 0.0 8:37.82 blkls 7942 root 20 0 29908 628 252 D 2.6 0.0 100:13.48 blkls 7943 root 20 0 29908 628 252 D 2.6 0.0 92:39.47 blkls 10085 root 20 0 29908 560 184 D 2.6 0.0 147:42.02 blkls 4170 root 20 0 29908 1148 768 D 2.3 0.0 7:43.02 blkls 4152 root 20 0 11580 724 596 S 1.3 0.0 2:42.07 grep 4172 root 20 0 11584 748 616 S 1.0 0.0 2:27.05 grep 10087 root 20 0 12104 1024 400 S 1.0 0.0 34:35.88 grep 10091 root 20 0 25088 1236 592 R 1.0 0.0 16:26.14 top 12433 root 20 0 177148 17996 3748 S 1.0 0.1 9:04.61 X 4133 root 20 0 11584 704 572 S 0.7 0.0 2:50.47 grep 1299 root 0 -20 0 0 0 S 0.3 0.0 2:05.53 kworker/2:1H [/code] And if I look up the logs, posting just what has changed: [code] ls -ltrR /mnt/g5n-C/autopsy/g5nCmn/g5n/ [/code] [code] [...] /mnt/g5n-C/autopsy/g5nCmn/g5n/logs: total 24 -rw-r--r-- 1 root root 4750 2015-05-07 07:19 miroR.log -rw-r--r-- 1 root root 10007 2015-05-07 07:19 miroR.exec.log [...] /mnt/g5n-C/autopsy/g5nCmn/g5n/output: total 4 -rw-r--r-- 1 root root 47 2015-05-06 18:56 vgn-Cmn-0-0-0.srch [/code] The one-liner in bottom first: [code] cat /mnt/g5n-C/autopsy/g5nCmn/g5n/output/vgn-Cmn-0-0-0.srch [/code] [code] 0||Z1_F0331_Zoom_Lovrić_Škaričić.avi|ascii [/code] Diff from previous log, as I already posted it in the first post: [code] diff /mnt/g5n-C/autopsy/g5nCmn/g5n/logs/miroR.log.PREV /mnt/g5n-C/autopsy/g5nCmn/g5n/logs/miroR.log 57,59d56 > Thu May 7 06:59:30 2015: vgn-Cmn-0-0: ASCII, Unicode, search for Z1_F0331_Zoom_Lovrić_Škaričić\.avi > Thu May 7 07:09:30 2015: vgn-Cmn-0-0: ASCII, Unicode, search for Z1_F0331_Zoom_Lovrić_Škaričić\.avi > Thu May 7 07:19:31 2015: vgn-Cmn-0-0: ASCII, Unicode, search for Z1_F0331_Zoom_Lovrić_Škaričić\.avi [/code] [code] diff /mnt/g5n-C/autopsy/g5nCmn/g5n/logs/miroR.exec.log.PREV /mnt/g5n-C/autopsy/g5nCmn/g5n/logs/miroR.exec.log 74,81d73 > Wed May 6 18:56:47 2015: '/usr/bin/blkls' -e -f ext -o 0 -i raw '/Cmn/autopsy/g5nCmn/g5n/images/vgn-Cmn' | '/usr/bin/srch_strings' -a -t d -e l | '/bin/grep' 'Z1_F0331_Zoom_Lovrić_Škaričić\.avi' > Wed May 6 18:56:47 2015: '/usr/bin/blkls' -e -f ext -o 0 -i raw '/Cmn/autopsy/g5nCmn/g5n/images/vgn-Cmn' | '/usr/bin/srch_strings' -a -t d -e l | '/bin/grep' 'Z1_F0331_Zoom_Lovrić_Škaričić\.avi' > Thu May 7 06:59:30 2015: '/usr/bin/blkcat' -f ext -s -o 0 -i raw '/Cmn/autopsy/g5nCmn/g5n/images/vgn-Cmn' > Thu May 7 06:59:30 2015: '/usr/bin/blkls' -e -f ext -o 0 -i raw '/Cmn/autopsy/g5nCmn/g5n/images/vgn-Cmn' | '/usr/bin/srch_strings' -a -t d | '/bin/grep' 'Z1_F0331_Zoom_Lovrić_Škaričić\.avi' > Thu May 7 07:09:30 2015: '/usr/bin/blkcat' -f ext -s -o 0 -i raw '/Cmn/autopsy/g5nCmn/g5n/images/vgn-Cmn' > Thu May 7 07:09:31 2015: '/usr/bin/blkls' -e -f ext -o 0 -i raw '/Cmn/autopsy/g5nCmn/g5n/images/vgn-Cmn' | '/usr/bin/srch_strings' -a -t d | '/bin/grep' 'Z1_F0331_Zoom_Lovrić_Škaričić\.avi' > Thu May 7 07:19:31 2015: '/usr/bin/blkcat' -f ext -s -o 0 -i raw '/Cmn/autopsy/g5nCmn/g5n/images/vgn-Cmn' > Thu May 7 07:19:32 2015: '/usr/bin/blkls' -e -f ext -o 0 -i raw '/Cmn/autopsy/g5nCmn/g5n/images/vgn-Cmn' | '/usr/bin/srch_strings' -a -t d | '/bin/grep' 'Z1_F0331_Zoom_Lovrić_Škaričić\.avi' [/code] Since I remember having had some issues with Autopsy on my system (grsec-hardened amd64 Gentoo), and seeing similar error in this attempt, I was wondering about the stage which I am at, and if I should go on, or quit waiting for the result (it's been just over two days this srch_strings is on). Or is it now that I'm half way through, if the one-liner from the output folder, [b]vgn-Cmn-0-0-0.srch[/b] said: "0||Z1_F0331_Zoom_Lovrić_Škaričić.avi|ascii"? That probably does mean a result of a search, and that [i]that[/i] ascii search is done... And the time of that result (IIUC) is 2015-05-06 18:56, almost a day ago... But why then did anew search start? I already had (this is part of what I meant "had some issues with Autopsy" above) the Autopsy interaction with Sleuthkit on my system somehow starting another time the MD5 calculation... Cuold this too be a duplicate, a duplicate search in this case? And these are (at least two things) what I meant when I said that I may possibly be doing it wrong: you see that I am searching for that string, and one thing possibly wrong (that's the first thing, and I'm not sure if it's wrong) is that the string I search for is the name of the file, and I remember I once found where a lost text of mine was, but I wasn't searching for the name of the file containing text, but for the sting that appears only in the text itself... And this is the second thing that I fear I'm doing wrong: I fear that this search won't help in the least to ease my later tries... I should have somehow dumped the unallocated space to be able to search in it (and I fear I can not do it now, not until this search is done)... And so, after this search is done, the search and some info (but I really don't get exactly which info) will be stored to ease future searches, but since the: [code] '/usr/bin/blkls' -e -f ext -o 0 -i raw '/Cmn/autopsy/g5nCmn/g5n/images/vgn-Cmn' | '/usr/bin/srch_strings' -a -t d -e l | '/bin/grep' 'Z1_F0331_Zoom_Lovrić_Škaričić\.avi' [/code] is searching through a pipe, any new search by blkls will have to be done all over again, because, as I said I should have, but didn't know how back then (and I am not certain now either, but I'll give my understanding below) I the blkls is not extracting and storing anything other than temporarily, and piping it to grep... My understanding now (and I'm really applying my best), is that I shouldn't have started that perl regex string search, as it's too long and giving too little result, and stored very little for future, but... But that I should have picked the "Keyword Search" from the other manu at the same level as the "File Analysis" in the main menu accessed through "Analyze" in the "Case Gallery", and... And that I should have chosen from the "Keyword Search of Allocated and Unallocated Space" page that then opens the "Extract Unallocated". Is my understanding above correct? Are those processes, but same search that started: [code] Thu May 7 06:59:30 2015 [/code] and: [code] Thu May 7 07:09:30 2015 [/code] duplicates, and should I kill those new processes? Should I go back and, as I said above, go for the "Extract Unallocated" rather than wait here at all, or should I rather wait for the remaining old (more than two days now chourning on) processes after I kill the new? Thanks if anybody offers an advice on this matter. The current Autopsy issues that I haven't yet explained (I did have it previously: Recover partly overwritten luks volume? https://forums.gentoo.org/viewtopic-t-1004014.html#7723732 where find: [code] uabox ~ # cat /Cmn/autopsy/WCC070-luks-vol/ukrabox/md5.txt 3B7E4DF6DA0E8BB78283BB66F317689B   img1 3B7E4DF6DA0E8BB78283BB66F317689B   img2 uabox ~ # [/code] ), and this could be for similar reason. I'm browsing with `links -g http:///autopsy as I was given the address by Autopsy, for this other host in my network, as I explained in the post immediately previous to this. After I started the search from the "File Analysis" section, hours later this error appears, and it keeps at it. I can only manually copy the screen, no copy/past available for this in the links framebuffer browser: [code] ================ Error =============== Error loading http:////autopsy?mod=... Receive timeout Cancel ====================================== The Error on top and the Cancel in bottom are clickable, but I never even tried to, remembering that I somehow got a duplicate work to go on the one last time linked above... And I think that links screen is anyway unuseable. I'm using another links instance for reading Help. Whatever the reason why the links shows this timeout, I suppose it is somewhere in that interaction btwn Autopsy and Sleuthkit via the browser that the duplicate work started, the last time, and maybe this time as well.