Cannot reproduce: HxD: Problems with large HDDs: Edit - copy as...

Bug reports concerning HxD.
Post Reply
Ernst@at
Posts: 1
Joined: 05 Apr 2009 13:22

Cannot reproduce: HxD: Problems with large HDDs: Edit - copy as...

Post by Ernst@at » 05 Apr 2009 14:40

Hello,

There exists a problem with the Menu/Edit/Copy as (or copy of marked block by <ctl+C>) to the clipboard
when using large disks (1,5TB) with Menu/Extras/open disk/physical disk.

Marked block at highest LBA numbers(containing Offsets(h) up to 15D50F65FF0) and a length of a larger number of LBA blocks (i.e. 2048 LBA's= block length of 0x100000 bytes) results in no output written to the clipboard; attemps with <ctl+C> ends up with "floating point exception".
As a circumvention, marking smaller block sizes (128 LBA's or a length of 0x10000 bytes) can be extracted with <ctl+c>/<ctl+V>, but at the "Editor view" copy the header contains 3 additional bytes in front:
" Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F" (the three front bytes content is 0xEFBBBF).

addition: the text translation works there sometimes incorrect (more than 16 bytes) and looks like:
15D50D01500 00 2C 55 08 80 FA FF FF 00 2C 55 08 80 FA FF FF .,U.€úÿÿ.,U.€úÿÿ
15D50D01510 10 2C 55 08 80 FA FF FF 10 2C 55 08 80 FA FF FF .,U.€úÿÿ.,U.€úÿÿ
15D50D01520 C2 00 02 0A 4E 70 46 6E 30 FB 96 09 80 FA FF FF Â...NpFn0û–.€úÿÿ
15D50D01530 5C 00 6E 00 76 00 73 00 72 00 00 00 00 F8 FF FF \.n.v.s.r....øÿÿ
15D50D01540 02 00 06 02 4E 56 20 20 00 00 00 00 00 00 00 00 ....NV ........



Please take into account that today's HDD sizes now extend to 2TB, logical array sizes of 5x2TB RAID0 may reach 10TB atm.

It would be nice to have an additional choice to select the block in the Menu/edit/select block popup:
start/end/length units not only to be interpreted in bytes, additionally in sectors would be practical.

best regards
Ernst

Maël
Site Admin
Posts: 1168
Joined: 12 Mar 2005 14:15

Re: HxD: Problems with large HDDs: Edit - copy as...

Post by Maël » 20 Apr 2009 16:53

Ernst@at wrote: Marked block at highest LBA numbers(containing Offsets(h) up to 15D50F65FF0) and a length of a larger number of LBA blocks (i.e. 2048 LBA's= block length of 0x100000 bytes) results in no output written to the clipboard; attemps with <ctl+C> ends up with "floating point exception".
I'm sorry, but I couldn't reproduce. What I did was: select the block 15d50e66000 - 15d50f65fff in a physical drive and use Ctrl+C. Then create a new file and paste using Ctrl+V.
Do these steps generate the error on your machine? If not please specify similar clear and easy to reproduce steps.
Ernst@at wrote:As a circumvention, marking smaller block sizes (128 LBA's or a length of 0x10000 bytes) can be extracted with <ctl+c>/<ctl+V>, but at the "Editor view" copy the header contains 3 additional bytes in front:
" Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F" (the three front bytes content is 0xEFBBBF).

addition: the text translation works there sometimes incorrect (more than 16 bytes) and looks like:
15D50D01500 00 2C 55 08 80 FA FF FF 00 2C 55 08 80 FA FF FF .,U.€úÿÿ.,U.€úÿÿ
15D50D01510 10 2C 55 08 80 FA FF FF 10 2C 55 08 80 FA FF FF .,U.€úÿÿ.,U.€úÿÿ
15D50D01520 C2 00 02 0A 4E 70 46 6E 30 FB 96 09 80 FA FF FF Â...NpFn0û–.€úÿÿ
15D50D01530 5C 00 6E 00 76 00 73 00 72 00 00 00 00 F8 FF FF \.n.v.s.r....øÿÿ
15D50D01540 02 00 06 02 4E 56 20 20 00 00 00 00 00 00 00 00 ....NV ........
This is expected behavior, "Editor view"-copy is not meant to used to copy/paste raw data, but the editor view such that a text editor can use it. The additional bytes are a Unicode BOM.

Moderation note: I split the topic into a bug-report and a feature-request.

Post Reply