I am interested in examining the "free space" on a HDD partition to confirm or refute the claim by a commercial store that it did wipe out all pre-existing data on that partition. In the past few years, I have appreciated the options in Okteta (from KDE) to be able to examine and change data within currently existing files. Now I'm wondering how it will be possible to peek outside the currently allocated space into the "vast outer nonfile-occupied space," or whatever it may be officially called.

In the documentation for the GUI version of Okteta, it shows a File --> New --> Empty menu option. Does that produce (1) merely a new file consisting of all zeros? or (2) a file of a chosen size which retains the leftover data residuum? or (3) a file which Okteta has forced me to create by choosing my own new data, which will overwrite the existing residents of those memory locations? If it is case (1), then I cannot learn whether the data was actually cleared by action of the commercial process or from my newly creaed file. If it is (2), then I can be sure that the zeros were the sole result of the commercial scrubbing.

When I initiate the File>New>Empty sequence in Okteta, it offers me a chance to set up a "New Byte Array." I interpret that to mean that it will dynamically destroy previous data by overwriting it in producing the new file whose bytes I specify in the Byte Array. In other words, (3) looks like the case which really happens.

So is there a way for me to not use File > New, but to somehow use Okteta to "peek" into the unassigned free space? Thank you

what about using an undelete utility or a forensic app/distro

Hi!

If you want to look at the bytes on your hard disk, you can use the "dd" utility. I have in the past successfully used it for data recovery already.
dd, when called like "dd if=/dev/sda1" (or similar) will just read raw bytes from your hard disk and write them to stdout. You can also redirect them to a file like "dd if=/dev/sda1 of=data.img bs=1k count=1024 skip=200 of=data.img"; that command would read 1024 1k-sized blocks starting at (200*1k) in your first partition and write them to data.img (where you could inspect them with okteta).
Be careful not to swap or confuse input- and output file (if= and of=), or you can easily erase data on your drive.

If you actually want to recover data, make sure that the first thing you do is dd'ing the whole partition (call without count= and skip=) to a file which is on another hard drive, and then continue recovery from that file. This ensures there's no further data losses, e.g. by the file system overwriting presumably un-used blocks.

For more information, read "man dd".
Note that the actual arrangement of data on your disk is probably highly chaotic and also depends on the file system you use.

Greetings,
Sven

I appreciate the suggestions from both google01103 and scummos. I am especially thankful to have you point out the /dev/sda1 path idea for getting inside any part of the partition, whether within a file, or out in free space. Thank you again. Dave