hi,
Possibly a dumb question that I havent thought about enough.

1. I write a pattern to the whole disk.
2. I tak an image of that disk with Partition Find and Mount.
3. I run HxD as administrator, and open both the image file and the physical Flash Disk that is still plugged in.
4. Tile both windows and scroll them both to the end.

Why is there a size difference?

in every instance there has been a huge size difference. sometimes drive shows bigger sometimes image.

Whats going on?

on case and below some others..

AIUI, PF&M would be taking an image of the partition (logical drive) rather than the physical drive.

I would examine sector 0 in each case. Is it an MBR or is it a boot sector? Does the capacity reported in sector 0 match the size of the PF&M image?

_________________
A backup a day keeps DR away.

I am writing the pattern with SC Pattern Writer app. I don't believe it writes a partition as after it is written, windows wants to format it.

The capacity of the flash drive is being rounded down to the nearest whole cylinder.

63 sectors per track
255 heads per cylinder

15197490 = 946 x 255 x 63
(15 204 351 - 15 197 490) / (255 x 63) = 0.427

16209585 = 1009 x 255 x 63
16214016

31262490 = 1946 x 255 x 63
31277056

15101100 = 940 x 255 x 63
15100256

15502725 = 965 x 255 x 63
15515648

_________________
A backup a day keeps DR away.

@fzabkar: if HaQue write pattern on flash, there is only pattern. No MBR, no FAT etc. Only 77 pattern sector.

Haque: make dump image with DMDE for example, but choose physical device, not partition.

_________________
Odzyskiwanie danych

OK will try it and report.

So the DMDE image shows the same last sector as the Physical Disk as I think it should. For some reason the Partition Find and Mount image is different. I don't know it the PFaM people have a different take on what to image, or if it is a bug. I will send of a question to them with my results and ask if that is by design, or if they have any insight. It is possible they don't support what I am doing, as the software is about finding partitions, not working in the absence of one. Or that the do something along the lines of what fzabkar has said. The do have a caveat after all..


This is the Physical disk opened in HxD Hex Editor, and the next pic is a comparison of the 2 images I took, first PFaM and secon DMDE.





some other info:

Size of physical drive = 3 913 344 LBAs

Using DMDE's two CHS combinations ...

243 x 255 x 63 = 3 903 795
970 x 64 x 63 = 3 911 040

It appears that PF&M is using the first set of CHS values. IIUC these values are coming from the SCSI driver.

_________________
A backup a day keeps DR away.

Thanks franc, yes I agree with that, and also agree with the rounding down of the cylinder. Actually, looks like a FLOOR operation, which just strips anything after the decimal point. I was unable to track down any proper specifications that show it, but was able to find a few references to rounding, enough to say that this is probably the cause. It would make sense for reasons such as wanting an integer value, not a float when coding drivers, BIOS and software interfaces.

Many many many supposedly technical manuals have words like "may" might" "could" "depends" etc when talking about LBA / CHS, including this hilarious Gem


pages like this http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat


and
http://eab.abime.net/showthread.php?p=938496



which, coincidentaly, was quite an interesting tangent

I think this puts the solved moniker on this