How many Blocks are on my screen?

[rodalsa1]

Moderators.  Not in the correct place?  Help me out.

 

Defraggler presents a pane on its operating screen that is called the Drive Map.  This Drive Map is said to represent the entire drive that the user has selected.  The Drive Map may be resized by the user and presents varying numbers of Blocks as resizing is undertaken.  This obviously means that the number of Bytes per Block varies as the user resizes the screen.  I wanted to know how many Blocks were present so that I could determine the number of Bytes each block represented.  Try counting the number of Blocks (better yet just look at the pane) for 1 x 1 Blocks and you quickly find that there has to be a better way.

 

There are a huge number of Block sizes measured in (x, y).  The range is  1 <= x <= 19 and 1 <= y <= 19.  I reduced the number to 19 by forcing x = y and obtained the results shown in the attached jpg..  I reviewed it and -- well, the jpg is there and that is about it.  I had to use this site's magnifier and then use the Ctrl - + feature of Firefox to its maximum to get my font size 20 to be readable.  Some of the smaller fonts that I used are not readable.  Too bad I could not upload my bmp.  If there is a way to make the bmp available to the viewers of this site, let me know.  NOTE:  The original file was created in a program named DeltaCad.

 

In the jpg I reference the ruler that I used in my analysis.  It is a shareware product (not mine).  I hope that this was OK.

[kroozer]

If there is a way to make the bmp available to the viewers of this site, let me know.

Convert your bmp to jpg or png at CoolUtils

 

[rodalsa1]

Thanks kroozer.  I tried it.  No change in quality.  In fact the file size went from 519 KB to 297 KB which I usually take as a reduction in clarity.  Both files were jpgs. One from me and one from CoolUtls.

[Augeas]

Not necessarily. Jpegs are highly compressed, and I don't think that bmps are compressed at all.

 

I'm not sure whether this should be in discussion or suggestions, as there doesn't seem to be an actual suggestion. Are you saying that there should be a figure saying how many bytes on the disk are represented within each displayed block? I guess that could be done but I don't write the software.

 

It's often overlooked that what any defragger shows is not actually what's on the disk but what is extracted from the file tables, which is not quite the same.

[Andavari]

In fact the file size went from 519 KB to 297 KB which I usually take as a reduction in clarity.

 

If you use PNG it's lossless like BMP is, shouldn't be any loss in quality - although for some images JPG which is lossy is more smaller.

[eL_PuSHeR]

PNG is better for screenshots than JPEG. The file will be even smaller just because JPEG lossy compression is meant for photographs only.

 

As for the OP suggestion, yes, I think Defraggler could inform about how many bytes and/or sectors per map block.

[rodalsa1]

I revised the jpg to a 826 KB file using a more direct translation approach.  The quality is better.  The bmp file was 8,572 KB.

 

Augeas.  Precisely.  By presenting a work that achieves an end not present in the software I made two suggestions implicitly.  #1)  This site does not have a place directly suitable for the content of my thread.  So why not add one?  #2)  Defraggler does not present the information that my work enables for those that have an interest in bytes/block.  Of course Defraggler presents the total bytes/drive which is dependent on the user's hardware so my work stopped at that point.  I give everyone the ability to find the total number of blocks on any Defraggler screen and Defraggler gives the user the number of bytes on their drive.  The user does the math.

 

Re graphic file translations.  I tried all of the allowed translations and only the jpg came in under the file size limit.  My suggestion here would be for the site to advise its users to #1)  use small originals or #2)  split large originals in to smaller chunks and submit multiple files or #3) the site allow larger file sizes.  Hopefully your users will get messages #1) and #2) before they invest copious time building their graphics.

 

Defraggler presents for my C: drive 124,763,471,872 as the number of bytes.  It is hard to believe that Defraggler gets this number while working with file tables.  I do not remember any such information being in those tables back 'in the day' when I worked directly with file allocation tables (FAT)s.  I would be more inclined to believe Defraggler actually counts the number of bytes unless there is a source for that number to be found elsewhere in either the sofware or hardware installed on each computer.  The drive's specifications list it as a 250.0 GB drive.  C: is one of 8 partitions on that 250.0 GB drive and has a reported capacity of 116.2 GB.

 

Ah the questions!  Defraggler reports 123,763,471,872 and 116.2 GB on the same line back to back.  I think 123.8 GB is more than 116.2GB!  Ah the questions!  Perhaps a sub-forum titled "Defraggler Technical Issues" is in order.

[Augeas]

I hope Defraggler doesn't count the bytes in a partition! Offset 0x28 in the Volume Boot Record holds the number of sectors in the partition: multiply that by 512 to find the total bytes in the partition (and indeed 124,763,471,872 is divisible by 512). There are probably other ways of quickly finding the partition size in bytes.

 

My point is that Defraggers don't look at the disk. They can't and it would be pointless. They defrag the cluster chains in the MFT/FAT, and this sends cluster remapping commands to the disk. A disk hasn't the foggiest what a file is, let alone whether it's fragged. So what you see when you run a defragger is taken entirely from the file allocation tables. What's actually in the disk controller's mapping tables is unknown. Which is perhaps straying from the subject a little.

[rodalsa1]

Point taken.  I should have known better.  Let's rest.