PassMark Software
Global (Go to Australian site)


No announcement yet.

Viewing/Decoding search results

  • Filter
  • Time
  • Show
Clear All
new posts

  • Viewing/Decoding search results

    Hi all, i was giving v1.1 final a try and have something to ask.
    My config is:
    Windows 7 ultimate 64, 8gb ram
    a suspect drive image (.E01 format mounted as "PhysicalDrive5" with FTK Imager)
    OSF v1.1 Final registered executed as administrator.
    new case->add device->physical drive->PhysicalDrive5
    create an index indexing "anything" with no problems and in a reasonable time.
    Now i do my first search and some possibly interesting results come out
    from unallocated clusters but when i double click on one of these results
    OSF says: "Unable to open file 7891822-7894381" "File not found".
    If i right click on one of these results and then click "Open" OSF says:
    "Unable to read disk, you must be running as administrator to view unallocated sectors".
    So i try to use "Raw Disk Viewer" to see the possibly useful stuff in its context.
    I select "\\PhysicalDrive5: Partition 0" (there is only one partition) in Raw Disk Viewer,
    then i click "Jump to ..." button and put the value 7891822 in the "Offset" field while checking "LCN" option and finally start scrolling sectors one by one searching from the relevant text but after 40 minutes i haven't been able to find the text block found via "Search Index".
    I think that the right behavior of the application after a double click on a search result from unallocated clusters should be to open the appropriate viewer pointed at the relevant disk sector. I understand that the condition of my test is a bit "unusual" but, at least, i think that the position of a search result refering to unallocated clusters should be pointed out with greater precision then "7891822-7894381" that is a 2559 LCN range ...

  • #2
    We were able to reproduce the problem. Looks like it might be a bug.
    We should have a fix in the next couple of days.


    • #3
      It was definitely a bug.
      Correction will be in the next patch release. Either tomorrow or Friday (4/May/2012).


      • #4
        V1.0 build 1001 is now released and this problem should be fixed.


        • #5
          Bug resolved


          i can confirm that the feature is now working.
          To say the truth i would like to see the the "Hex/String" viewer
          opening directly on the relevant area of the finding while at the
          moment it opens on the first logical cluster of the range and
          i have to narrow down the search (quickly) clicking the "Extract Strings"
          button, then i click on the interesting string and finally the viewer shows
          the area containing the finding.


          • #6
            Yes, this would be nice.
            It isn't trivial to do well however. The problem is that often we can't do a straight string search to find the word in the document (or block of clusters in this case).

            A straight string search isn't possible because often the match will be the result of wildcards, stemming, or involve different character sets (Unicode instead of ASCII).