The first While loop works as expected, otherwise the program would report the wrong max head count.

I'm using Version 5.11 (build time April 28 2015). Which version/fork are you using?

_________________
A backup a day keeps DR away.

all is same.. 27april 2015 64 bit though.

Can you try a linux compiler ?

Its strange, if you are experiencing this, likely some others would have also experienced it?
people should post..its 75 downloads already.
--

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

Like fzabkar I used your code to reconstruct something in freebasic so I could mess with other things.

_________________
Data Recovery Services in the UK.
https://www.usbrecovery.co.uk/

I tried another charger today. Parses till 1.7TB instead of 1.8TB.
The HM created in 3k creates chains/serpentines (whatever you call them) till 1.7TB only with 512 size.

--

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

Fzabkar, how did you convert 512 /4096 (Multiplier of 8 ) ?
--

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

@sin, I refer to the "zones" as serpentine segments because that's what others call them:

https://hddscan.com/doc/HDD_Tracks_and_Zones.html

I apply the LBA size to the total LBA count at the end of my program. I always use 512 bytes as the default because I can't tell which is appropriate for that particular model. I took your Palmer and Charger examples and calculated the total capacity based on 512 bytes. When that didn't produce a sensible capacity, I tried 4096 bytes, but that didn't make sense, either.

I am currently limited to Win 10 32-bit, so I can't compile for Linux.

I suspect that nobody has been able to reproduce the problem because they all moved on to 64-bit years ago. You could probably reproduce it if you were to recompile your tool for 32-bit by using the "-m32" option in the command line.

I am now wondering whether your previously stated failure to write more than one byte at a time to your DDI map file may be indicative of another bug in the compiler.

If anyone else is experiencing my problem, here is my FreeBasic tool:

http://www.users.on.net/~fzabkar/FreeBasic_W32/Utils/deddimap.bas
http://www.users.on.net/~fzabkar/FreeBasic_W32/Utils/deddimap.exe

_________________
A backup a day keeps DR away.

Nice code - comments and error handling too

I'm too ashamed to show the nasty hack I made particularly with the endianness and ubytes

I've turned my attention to the head.map file DE creates by default rather than an export of the submapped heads (which I can't actually see how to generate here anyway). Slow progress - I'm thick as two short planks

_________________
Data Recovery Services in the UK.
https://www.usbrecovery.co.uk/

Sounds just great.. Infact my findings are just done now
The way head.map stores info is pretty cool.

I am really wondering if i should use C to code a new tool or python...or perhaps code in both (to learn and advance my skill set).

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

Just offtopic: What kind of skills would one require to work for a tool mfg ?
I understand that their dev team consists of constants (core team) and variables (contractors).
What do such companies look out for in a candidate to have them on board?

--

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

@sin, I have one more observation. As you and I are both using SSDs, I'm wondering whether writing a 2GB file, one byte at a time, will prematurely wear out the drive. I checked my SMART data, and ISTM that it shows 1TB more writes than I expected.

_________________
A backup a day keeps DR away.

LOL quite possible too... I started with about 4tb overall lifetime writes on sentinel and now it is about 6TB.
No health falls noted.......One can always run the tool and make a binary map on a PD for that matter.

this has remained constant
The health is determined by SSD specific S.M.A.R.T. attribute(s): #177 Wear Leveling Count

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

Yeah, my wear levelling count hasn't changed, either, so it looks like caching may have prevented undue wear ???

_________________
A backup a day keeps DR away.

LOL
Yes, caching is saving you. I have only briefly looked at the c++ code, but from what I can see the call to filewrite will probably invoke the actual final write when fclose is called. The single byte write loop will be cached as the OS desires until the fclose, although even then it could still be cached by the OS.

FYI if there were really that many single byte writes to the drive, it would be very slow, even with the SSD.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

I downloaded this Dev-C++ fork ...

https://github.com/Embarcadero/Dev-Cpp/releases/download/v6.2/Embarcadero_Dev-Cpp_6.2_TDM-GCC_9.2_Setup.zip

... but it still has the same bug.

The date stamps of the compiler (g++.exe) are 6 years apart (2020 versus 2014).

The new version produces a 2.4MB EXE whereas the old version produces a 1.4MB EXE ???

_________________
A backup a day keeps DR away.

thanks for the input...I will try to write in some other way. Writing with arguments as per syntax and not via the for loop causes parts of same .map file to be written into the parsed file
I have seen some strange country names too.... if i use fwrite(&BinaryHeadNumber, 1, length_of_Sectors , binary_map);
--

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

As an update, windows task manager shows write speeds of about 25megabytes per sec.

--

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

It's not a bug in the compiler, it's a bug in your code.

You have declared temp_read_length_buffer as an array with 7 elements (0 to 6), but the FOR loop writes to temp_read_length_buffer[7]. It would appear that temp_read_length_buffer[7] occupies the same location as footer[0], so that is the reason that the footer is overwritten.


This code works correctly:


My apologies to the developers of GCC.

_________________
A backup a day keeps DR away.

I will surely install a windows 7/10 32bit and try this out myself.

Unsure, why the code would work for me.

To verify your claim, you can always print the address with printf with & sign for argument.

--

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

I suspect that the 64-bit version of the compiler stacks the variables in RAM in a different order. Even if you see no problems now, there may be an insidious problem which may show up if you make updates to your code.

I have already verified my claim twice in previous posts with appropriate debug lines.

You don't need to install a 32-bit version of Windows. You just need to select the 32-bit compiler in the Dev-C++ menu options.

_________________
A backup a day keeps DR away.

Ok, let me try...thats why there are BETA testers
One man job and army gets difficult.

Thanks for pointing. The machine I am running is i3 , 2nd gen with 2Gb ram.


--
PS: If time allows and 3k supports, I will do HM of a 12TB Seagate Exos drive and share the map.

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.