WinHex 11.9 Log Out | Topics | Search
Moderators | Edit Profile

X-Ways Forum » Public Announcements » WinHex 11.9 « Previous Next »

Author Message
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Tuesday, Nov 16, 2004 - 20:34:   

A beta version of WinHex 11.9 is now available here.

What's new?

* WinHex now allows logical search operations in files and folders that are selected in the directory browser, even if a partition is available e.g. as an image file only and not mounted as a logical drive letter in Windows. The Parallel Search command for this can be found in the directory browser's context menu. (specialist or forensic license only).

Advantages and disadvantages:

+ The search scope can be limited to certain files and folders, also certain files and folders that are part of a contents table.

+ Searching in files (usually = in the cluster chains allocated to files) is a "logical" kind of search. Will find search term occurrences even if the search term happens to be physically split in a fragmented file (occurs at the end and the beginning of discontiguous clusters) and even if the file is compressed (at the NTFS file system level or in an archive such as ZIP, RAR, etc.).

+ Files in which the searm term occurs can be automatically opened.

- Unlike a search operation on a partition = search in a partition's sectors (= a "physical" kind of search), does not include unallocated space, slack space, or special system areas such as file allocation tables or logical surplus sectors. Also it is not as fast as a physical search.

* There is no duplication of search hits in the Position Manager any more. E.g. if you first search physically and then logically on a partition and have WinHex archive search hits, only additional hits will be added.

* Annotations manually added to evidence objects are now maintained and reported separately from search hits. Important search hits can be moved to the list of annotations with the Position Manager's context menu. Search hits are now collectively recorded with the date and time when the search operation began (useful for sorting by two criteria).

* The UDF file system is now supported in addition to FAT, NTFS, Ext2/Ext3, and CDFS/ISO9660.

* WinHex can now estimate the original size of MS Office documents when recovering such files "by type" and can now also distinguish between MS Excel, MS Word, and MS PowerPoint files and name them accordingly. (since v11.8 SR-3)

* WinHex now understands both ways of numbering raw image file segments, .000-based and .001-based. Newly created image file segments will now start with .001 instead of .000. (since v11.8 SR-3)

* WinHex now tries to identify obvious deleted partitions automatically and can scan for further formerly existing partitions in unpartitioned disk space when you invoke Tools | Disk Tools | Scan For Lost Partitions.

* Contents tables are now loaded back into the directory browser at twice the speed. Unloading large contents tables has become similarly faster.

* The directory browser can now sort in reverse order, and still reveals the previous order with a lighter arrow. For example, if you first click the filename column and then the filename extension column, files with the same extension are internally still sorted by name. Also the directory browser can optionally now be displayed with a grid.

* The directory browser has new icons for deleted files and folders. Deleted objects that WinHex knows are no longer accessible (either because their first cluster has been reallocated or because they have a size of 0 bytes) have icons crossed out in red.

* There is now a tooltip that indicates the path of a file if you place the mouse cursor over its icon in a contents table.

* There is now a small extra button (a floppy disk icon) that allows to save changes to a contents table, after deleting irrelevant files or directories from it, without having to close the directory browser.

* It is now possible to create drive contents tables for all evidence objects in a case without further user interaction in one step.

* A new option allows to create a case wide global contents table, by unifying contents tables from various evidence objects. The menu command for this can be found in the Case Data | Edit menu. Such a unified contents table is the most powerful way to review all files from all directories, from all partitions, from all media and image files that belong to a case. (forensic license only)

* There is now an option under Edit | Convert that allows to stretch 7-bit ASCII, which can be found e.g. on mobile phone SIM cards, to 8-bit ASCII.

* There are now script and API commands that allow to interpret raw images, Encase images, and evidence files like physical disks or partitions, as known from the Specialist menu command.

* It is now possible to select a track of a multi-session CD for display in the directory browser.

* It is now possible to include data analysis charts in the case report (via the context menu).

* Depending on which encryption algorithm was used, it is now possible to decrypt files inside encrypted ZIP and RAR archives if you know the original password. (forensic license only) Owners of a forensic license please log in and download a new zip.dll library for use with WinHex 11.9 Beta here.

* Many other minor improvements.

The program help has not been updated yet.

If you have a forensic license, please add the missing files for forensic functionality from X-Ways Forensics 11.8. WinHex 11.9 will be a free update for all users who purchased WinHex 11.0 or later.

Please report errors here or by e-mail. Thank you.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Wednesday, Nov 17, 2004 - 3:49:   

Thanks, Stefan, I'm looking forward to trying the logical search enhancement! I noted that a search can include the contents of at least certain archives. Do the archives include GZ files? I ask because I've tried some tools that claim to search those particular archives, but in fact do not. Those archives often contain email related data from certain webmail services.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Wednesday, Nov 17, 2004 - 16:09:   

Yes, with a forensic license, the contents of ZIP, RAR, ARJ, GZ, TAR, and BZIP archives can be explored, extracted, and searched.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Wednesday, Nov 17, 2004 - 17:21:   

Ah ha! Perhaps I'll have to upgrade my license. I'm trying to check out the Parallel Search command by using the context menu from a folder in my directory browser, but the command is not there. Am I doing something wrong? Thanks.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Wednesday, Nov 17, 2004 - 19:01:   

Sorry, it's "Simultaneous Search", not "Parallel Seach".
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Wednesday, Nov 17, 2004 - 21:28:   

The Simultaneous Search command can be applied to any number of files and any number of directories in the normal directory browser view, but only to files in a contents table.

This is because a contents table is a flat view and does not support browsing directories, i.e. there is no "Explore" command and double-clicking does not open a directory either. Directories are of secondary importance in a contents table. If you are interested in a directory-wise approach, I recommend the normal directory browser view.

If you apply the Simultaneous Search command to one or more directories, the search is applied to that/those particular directories and all its/their subdirectories.
Top of pagePrevious messageNext messageBottom of page Link to this message

ross@winpro.net
Posted on Wednesday, Nov 17, 2004 - 23:17:   

> The Simultaneous Search command can be applied to any number of files

How can I set the "Cond: offset mod" to just apply to the first X=### range of a file?

To clarify, If I am using simultaneous Search in Directory Browser on a folder or selection of files and want to search the selected files for a specific string at the 10th byte only in each file.

P.S. the Position Manager limit during Simul Search in DIR BROWSER in WH11.9beta does not always appear to work (limit is exceeded).
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Wednesday, Nov 17, 2004 - 23:53:   

To search for a specific string at the 10th byte in each file (i.e. at offset 9), select

Condition: offset mod 2000000000 = 9

The divisor should be simply any very large number (2^31-1 is the maximum). This ensures you don't get many false hits.

E.g. the
condition: offset mod 10000 = 9
would also be met for the offsets 10009, 20009, 30009, ...

The trick is, there probably aren't many files as large as 2 GB.

--

If you find out specific circumstances when the limit is exceeded, please let me know.
Top of pagePrevious messageNext messageBottom of page Link to this message

ross@winpro.net
Posted on Thursday, Nov 18, 2004 - 3:14:   

> Condition: offset mod 2000000000 = 9

I had tried something like that (i.e. replacing the X=512 with 123456789 and it still found the same number of hits. Here is the test I tried, see where I went wrong:

Use WH 11.9Beta, open the logical drive and folder that contains the 'winhex-beta.zip' file -> in the Directory Browser right click the 'winhex-beta.zip' file -> choose Simultaneous Search -> enter the letters 'pk' (no quotes) in search for 'text fragments' box -> set Cond: offset mod = '123456789' (or any large number) -> select 'Search: ALL' -> check 'Archive occurrence positions:Position Manager' -> click 'OK' -> enter '100' for the 'Maximum number of positions to save' -> clisk OK and the number found should stop at 100 (the first time) (I was hoping for only the fist occurrence to be found, what did I do wrong?), now repeat the above and 141 positions are found instead of 100 and Position Manager opens with an interesting first entry:

" FFFFFFFF "pk" in "Drive D:" - \winhex-e.zip\winhex.hlp (exact offset on partition not defined)".

Please, let me know my error, thank you.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Thursday, Nov 18, 2004 - 22:29:   

1) Sorry, logical simultaneous search did not respect the condition option yet... Fixed with WinHex 11.9 Beta A.

2) There are 141 logical occurrences of "pk" (not case-sensitive) in that file. If you select to save 100 search hits at max, WinHex will save the first 100. If you then search again, the first 100 hits won't be saved again (see above feature description: "There is no duplication of search hits in the Position Manager any more."), so it continues and saves the following and remaining 41 hits and reports 141 total hits found. (Would have stopped at 200 at max. = 100 new hits saved.) Changed with Beta A to avoid confusion.

3) The offset of a particular search term in a data stream cannot be expressed as a partition/disk offset if the data stream is compressed.
Top of pagePrevious messageNext messageBottom of page Link to this message

ross@winpro.net
Posted on Friday, Nov 19, 2004 - 3:28:   

Thank you very much for the fix. It is much better.

However, I do notice that using the same search routine outlined above, WinHex indicates that it has examined 2.7MB of data (on a 1MB file) and when the search occurred, I used the pause key to see that other files were being searched (files NOT selected) this does not not happen with every search though but when it does happen it can always be repeated.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Friday, Nov 19, 2004 - 10:02:   

If a 1 MB .zip archive is searched logically that contains 1.7 MB of uncompressed data, a total of 2.7 MB is searched. This is the very nature of a logical search as outlined in the feature description above. Is that the phenomenon you are referring to?
Top of pagePrevious messageNext messageBottom of page Link to this message

ross@winpro.net
Posted on Friday, Nov 19, 2004 - 17:57:   

YES, VERY SORRY ... That is exactly what is happening.

BTW that is way too cool of a feature!

Thank you.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Friday, Nov 19, 2004 - 19:13:   

On an NTFS volume, I created a drive contents table to look for files with a certain name pattern (XYZ*). The file of interest was in an orphaned path ?\ABC\. From the DCT I created, I could not copy out the file, but was advised to "open the corresponding volume first."

I can copy out non-orphaned, deleted files from a DCT. If I open Deleted Objects, I can copy out XYZ from the root listing, or I can open folder ABC and copy out XYZ from there. I just wonder why I can't copy orphans from a DCT, but can from Deleted Objects.

BTW, should we post all questions/comments on the beta here, or use the customary topics for issues like this? Thanks.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Friday, Nov 19, 2004 - 20:41:   

That was an error, thanks for your exact description. Fixed with now WinHex 11.9 Beta B.

Please do post issues like this here.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Friday, Nov 19, 2004 - 23:57:   

Thanks, Stefan, Beta B corrected the problem. I may have found another issue however, as I plod along. In Beta B, I chose to create a Directory CT from the context menu at Documents and Settings on the same NTFS volume (image set). I checked Files, Dir's, Existing, and Non-existent, and the file mask was *.*. I proceeded once with, and once without, the thorough search option, and the result was the same. The DirCT found zero objects, although the directory actually contained seven subdirectories.

I went back and tried 11.8, SR-10, and it did list the seven subs. But, am I mistaken or should the DirCT recurse through the selected folder and list all subdirectoties and files? If not, that could be a handy feature to consider. Thanks again for the great support!
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Saturday, Nov 20, 2004 - 2:02:   

> the file mask was *.*

The seven subdirectories probably do not contain dots in their names.

As of WinHex 11.9, only "*" matches all names. "*.*" means "names with a dot somewhere". In short: Filename filters are interpreted more accurately. They are also more flexible now in that they may now contain up to two asterisks if they occur at the beginning and the end.

Will change that such that the filters are not applied to directory names.

Will add the ability to list the contents of subdirectories on an NTFS volume.
Top of pagePrevious messageNext messageBottom of page Link to this message

ross@winpro.net
Posted on Saturday, Nov 20, 2004 - 2:05:   

Possible error(s) re: WH11.9BetaB (and WH11.8-SR-10)

The WH11.9betaB Directory Browser does not display the Directory count the same as WH11.8-SR-8

Tested using W2k host - the examined source is the host as a logical drive (i.e. the "C:" drive)

In the Directory browser:

WH11.8-SR-8 includes a display format such as:
"29 files, 17+1 directories"

betaB leaves out the +1 on 17+1

WH11.8-SR-10 on the same source:
"17 files, 14 directories"
12 files and 3 folders are missing from the Directory Browser, even the "Programs" folder is not displayed in the Directory browser. I am not sure what I have done but it is not the attributes because files with 'SHRA' are displayed? A purge of CFG etc. files did not help.

--------------------------
next,

The Access menu does not always display the file or folder name, it will sometimes just list "(dir)" without inlucing the foldername.

-----------------------
next,

W2k Host, WH 11.9betaB, source=NTFS HD with logical damage:

Here is an error log re: using a Drive Content Table.
----------------
11/19/2004, 13:40:27
WinHex 11.9 Beta B Error Report
Windows 5.0.6150 (NT)

Sectors that were read last:
27: 6291510-6291511 (NTFS, 233 GB)
27: 6291510-6291511 (NTFS, 233 GB)
27: 3399536-3399543 (NTFS, 233 GB)

An exception error occurred at offset 004A6DB3 when I...
--- *** ---

My actions = use DCT in DirBrow -> select a folder (e.g. Winnt) -> right click -> drop down menu -> choose Go to FILE record -> in Access menu choose "(dir)" -> Explore -> crash = "An exception error occurred at offset 0046BF46 ...":
or crash = "Program Error WinHex.exe has generated erros and will be closed by Windows. you will need to restart the program. An error log is being created." (I assume this is a different error log? One form Windows?)
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Saturday, Nov 20, 2004 - 16:24:   

Beta C:

1) Filename filters for contents table creation are no longer applied to NTFS directory names.

2) Subdirectories on NTFS volumes fully included.

3) Access button menu will again show the name of the directory that a currently displayed FILE record defines.

--

> betaB leaves out the +1 on 17+1

The "virtual" folder "Deleted Objects" is no longer counted.

> 12 files and 3 folders are missing from the Directory Browser

Temporary bug in WinHex 11.8 SR-10 fixed with SR-11... Thanks for making me aware of this.

Cannot readily reproduce the exception error.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Sunday, Nov 21, 2004 - 0:53:   

Using Beta C, and this time the correct mask "*", I tried to create a DirCT on an NTFS volume for a directory that contains three files. I also selected the same options as in my earlier post, and tried exporting to the browser and to a file. Zero objects were reported. I tried the same approach with 11.8/10, and the three files were properly reported. Thanks.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Sunday, Nov 21, 2004 - 2:55:   

You are right, it works for directories at the first level only. Will be fixed shortly with Beta D.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Sunday, Nov 21, 2004 - 14:10:   

Beta D:

* Previously, there was a small chance that WinHex was unable to determine the location of a file or directory on an NTFS volume, and a warning was displayed in that case. The probability of such a case has been considerably further reduced.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Monday, Nov 22, 2004 - 17:41:   

When creating a DirCT with the option checked to Open file in MS Excel, an Excel file does not open, although the text file is created. Also, the signature file does not open when I click on the Customize button, as it does when I do so from the recovery by type box. Thanks.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Monday, Nov 22, 2004 - 18:33:   

> Open file in MS Excel

Will be fixed, thanks.

> the signature file does not open when I click
> on the Customize button, as it does when I do
> so from the recovery by type box.

You mean, when creating a drive (not directory) contents table with a [x] File header signature search in unallocated clusters? That does work normally here, cannot explain, sorry.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Monday, Nov 22, 2004 - 18:39:   

Sorry, I wasn't precise. File Type Signatures.txt does open when creating a Drive Contents Table, when I click Customize. It does not open when I click Customize when creating a DirCT. It also opens fine when I click Customize from the Recovery by Type window.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Monday, Nov 22, 2004 - 18:46:   

It should not be possible to execute a file header signature search when creating a directory contents table in the first place. The checkbox should not be visible, and the dialog window with the Customize button should not pop up either. I cannot explain why it does. What file system is this, please? Could you send a screenshot of the "Create Directory Contents Table" dialog window, please?
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Monday, Nov 22, 2004 - 19:02:   

Screen shot is on its way. It's NTFS on XP Pro.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Monday, Nov 22, 2004 - 19:05:   

Ah, thanks, now I understand. Of course you are referring to the Customize button directly in the "Create Directory Contents Table" dialog window. Will be fixed, thank you.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Monday, Nov 22, 2004 - 19:51:   

Beta E available.

Owners of a forensic license please log in and download a new zip.dll library for use with WinHex 11.9 Beta E here.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Monday, Nov 22, 2004 - 21:44:   

It's my day for Contents Tables. Using the latest beta and creating a DirCT on an NTFS volume with the option to report mismatches, the table correctly reported two files that I created in one directory to test how they're reported. One file was a JPG-extensioned file with an unknown header, and the other was a JPG-extensioned file with a GIF signature. The directory contained a total of four files, including the two described above. The other two were "correct" files. The former was "unknown," and the latter was reported as "GIF!".

I then created a Drive Contents Table (DCT), and the Mismatch field did not report any data for either mismatched file. The resulting browser window did, however, append the GIF extension to the GIF-headered JPG file.

In both cases, I selected Files, Directories, Existing, Mask="*", Detect filename..., Text file, and Directory browser. I have not tested this to see the results in any previous version. Thanks.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Monday, Nov 22, 2004 - 21:47:   

I hit send too soon. The sentence, "The former was "unknown," and the latter was reported as "GIF!", refers to the test files that I created. Sorry.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Monday, Nov 22, 2004 - 23:29:   

Cannot reproduce this here... Please provide specifics if you find out under what circumstances exactly this occurs. However, I found out the mismatch data might have got lost if a contents table was edited and saved right within WinHex (with the red floppy disk icon). Fixed now with WinHex 11.9 Beta F.

Program help now updated with v11.9 features.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Tuesday, Nov 23, 2004 - 0:20:   

Thanks, Stefan, I'll email an explanation and the files for your convenience and so we're working with the same objects.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Tuesday, Nov 23, 2004 - 21:12:   

As Stefan suspected, the issue arose not from WinHex, but from the way in which I sorted my Excel spreadsheet. I had sorted by using the A-Z button when in the Path field. While that should sort the entire sheet based upon the Path field, the spreadsheet contained two empty columns, which I believe resulted in a skewed view when I applied the sort. The empty columns preceded the Mismatch field, which contained the correct data. Also as Stefan pointed out, you can be sure to capture the entire sheet in a sort by Ctrl-Shft-End'ing in A1. If you do, then you must sort manually and not with the button.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Wednesday, Nov 24, 2004 - 19:07:   

For the benefit of those who have not experimented with the Excel Contents Table sorting matter discussed above, I thought I'd mention that the empty columns do cause the skewed result, if you simply sort a field with the A-Z/Z-A buttons. When I named the empty columns, I could use the buttons without that problem.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg (Jw)
Posted on Friday, Nov 26, 2004 - 21:28:   

I used Beta E to recover files by type from an NTFS partition. The log indicated that one file was recovered from offset 29091786752-29091836751. To check this, I went to Offset 0 of the partition, then used Position\Go to Offst 29091786752 (decimal), relative to current position. Then, I used the context menu to mark that offset as the beginning of my block. From that point, I tried to use Position\Go to Offset 29091836751, relative to current position (29091786752). WinHex reported that the disk does not contain offset 58183623503, which is correct, and which is the sum of the offsets. The last offset is 40015954928.

I could, however, mark my block as planned if, when using Position\Go to Offset [second], I chose relative to beginning of file. I thought that I should have been able to mark my block as I had first tried. Thanks.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Friday, Nov 26, 2004 - 22:54:   

Both offsets given are absolute offsets = offsets relative to the beginning of the partition (offset 0). It's easier if you use Edit | Define Block, where you can copy and paste both offsets in the same dialog window.
Top of pagePrevious messageNext messageBottom of page Link to this message

Anonymous
Posted on Monday, Nov 29, 2004 - 11:31:   

11.9 bug:
Open a cd with the raw sector flag set.
You can do a whx backup of the disk, but you cant do an image.


Also, I noticed that if an error occurs while a winhex output file is generated (dirve contents, backup, etc.) and you try to do it again to overwrite that file, winhex will say the file's busy and force you to pick another name. (the pgm dont release the open file after error)
Top of pagePrevious messageNext messageBottom of page Link to this message

Anonymous
Posted on Monday, Nov 29, 2004 - 11:42:   

wish list:

1. If you're at a file's MFT entry(NTFS), there should be a way to jump to the beginning of the file by way of the access button without traversing through the directory browser. (like you can with FAT)

2. While viewing a disk(NTFS), there should be a way to 'block' a file from the browser or access. (like you can with FAT)

3. the ability to search (or multi search) only data sectors, or only free sectors.

4. ability to select multiple blocks.
Top of pagePrevious messageNext messageBottom of page Link to this message

Anonymous
Posted on Tuesday, Nov 30, 2004 - 11:10:   

In 11.9, try this:
Do a drive contents table to the browser.
Sort by file record.
The result is not actually accurate when compared to the mft. All the directories are placed first.


Also, when I look at a multisession cd, I always notice one less partition. Example: 2 partitions on a 3 session disk.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Wednesday, Dec 1, 2004 - 17:59:   

> Open a cd with the raw sector flag set.

Thanks for making me aware of this. Since v11.9 SR-1, there is now a message in such a case saying that no image can be created with this command.

> the pgm dont release the open file after error

Yes, this is normal, given the circumstances. That the error occurs in the first place is not normal, of course. If you can provide details about it (e.g. send your error.log file by e-mail), that might be very helpful, thanks. Please download the latest release.

> The result is not actually accurate when
> compared to the mft. All the directories are
> placed first.

The result is accurate, as far as I can tell. That directories are listed first, followed by files, is obviously by design. Or else file and directories would be mixed already when sorted by name.

In other words: The sort criteria "filename" and "FILE record offset" have no priority over the criterion "item type" (directory or file).

> Also, when I look at a multisession cd,
> I always notice one less partition.
> Example: 2 partitions on a 3 session disk.

If WinHex offers to interpret the 2nd of 3 sessions, and you decline ("No"), the only choice left is to interpret the 3rd session. Obviously there is no point in asking a third time. Is that what you observe? You can see the selected session/track number in the details panel if you would like to verify.
Top of pagePrevious messageNext messageBottom of page Link to this message

Anonymous
Posted on Friday, Dec 3, 2004 - 17:38:   

11.9sr4

problem with recover by type:

Do a file recover by type (jpg)(list files only)
In the browser, select more than one entry.
Right mouse click & do recover/copy.
I get an error because it tries to copy to a "#" folder even if I specify a different destination folder. Same with recover by name.
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann (Admin)
Posted on Monday, Dec 6, 2004 - 1:04:   

Thanks. File Recovery by Type error when output to directory browser and recovered/copied with the context menu fixed now with v11.9 SR-6.
Top of pagePrevious messageNext messageBottom of page Link to this message

Anonymous
Posted on Wednesday, Dec 15, 2004 - 16:50:   

Minor bug: (sr9) display refresh problem

Sometimes when I click on something in the browser window, when the editor window changes, the vertical line drawn after the ascii text disappears (editor window maximized). Minimizing, then restore the window brings the line back. (nvidia video).

Also, for every new SR-? version that gets released, can you also list the bugs that got fixed on your website?
Forum operated by X-Ways Software Technology AG.