bleachbit wipe free disk space doesn't work

OK it always has taken close to a half hour but why am I able to recover all these files with the foremost forensic tool. I have tried from the root bleach bit, regular bleachbit and also gksu bleachbit in case the root option bleach bit offers wasn't working. Oddly I don't recognize any of the jpg or avi files but they are there even after I shred the recovered folder with bleach bit and run foremost again. They seem to be like icons and screenshots and the avi's look like animations for a OS like a folder tranfering files to another folded ect... its weird. Anyway when I go to preferences and then drives I selected /home and in root bleach bit I selected /tmp and /root. I have other partitions but am only using foremost on the one with mint sda2. So if I'm running bleach bit and select /home does that mean its gonna clean that folder and its subdirectories. And if so why don't I see other partitions as an option even though I'm not trying to wipe them now. I guess the best thing is walk me through it because something is wrong. Foremost found several gigs of jpg's alone. They weren't sensitive but I'm trying to see what is going on here especially because as I said I don't recognize these odd jpg's. I'm thinking they are leftover from someone else who had thisold laptop before me but still it surprises me since I've been using bleach bit since I got the laptop from them. Some icons were even windows icons And I never had windows on here but the other person has.

For foremost I used: " foremost -t avi /dev/sda2 -o ~/recovered"

Is this command not for just free space I'm starting to think I'm using foremost wrong or something. I was thinking that it's finding all the images on the partition not just deleted ones and that all the icons and animations etc.. are part of gtk or something. The only thing that makes me think otherwise is when I did text files it only found like 5 and that's not all my text docs. Sluethkit has a tool called DLS that images only free space and I can pipe that to foremost just to make sure its only doing free space. I'll do that tomorrow and let you know if that was it.

OK I used blkls which is the new name for the DLS tool in the sluethkit. This tool can read raw data form unallocated space on an image/drive. I piped this to foremost to make sure it was just checking free disk space. Here is the command

blkls -A /dev/sda2 | foremost -t jpg /Dev/sda2 -o ~/recovered

After this the same jpg images as before show and I ran bleachbit on my / , /root , /home /home/"myhomedir" manually as well as auto via check box for wipe free disk space. I also used shred feature to delete the recovered folder containing these images from my previous foremost results. I think its safe to say bleach bit is not doing its job in my case. If you think my methodology is flawed please tell me where as I would like to resolve this as much as anyone

ok i'm using mint13 xfce kernel 3.2.0-23-generic ext4 fs. my whole install is on sda2 no seperate partitions for /root /home or /opt because my other non-mounted partitions are for a diff OS. below is all my info for df and bleachbit set-up and errors

***besides wipe i have all boxes checked that are relvent cleaners***

df: `/root/.gvfs': Permission denied
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 146235696 93967392 44946704 68% /
udev 1536908 12 1536896 1% /dev
tmpfs 617668 956 616712 1% /run
none 5120 0 5120 0% /run/lock
none 1544164 84 1544080 1% /run/shm

for root bleachbit my folders in the edit-permissions-drives tab are as follows
/
/root
/dev
/home
/home/"myuserdir"
/run
/run/lock
***( i have tried others but based on df i did these)***

i always get permissioned denied errors in gui even as root when running bleachbit here htey are
[Errno 13] Permission denied: '/tmpKMFYK8E8PpmQ3wHCcwH2yYniseNImS9LYjsVe5oRMX45ZmJgCV.gPMN2lPqLHPj8YRRUll sx5YCEvmIz3sMSFp9bDphdTwrgaYdXn7FP7lA9ggIYyITWJ9frR2Yp740A9kFHmIaMwYUitxZaZX4CYG_K7g5gOIMxgz9mBN1iFtJ7ew3 PwDds7nlEM8xA5-apJ7ADfCfbrrpFcePy-aNp6fAj9rGo.-4r3KYt02YrlunFcEwt97QU3IQki'
[Errno 13] Permission denied: '/home/tmpge6oTk0a beyfHekUi8EaQQ3kfPlfO99yb4wrPUgYNZS085vDbs4bVr7fZYn6vRyRpivb7CzchkxOz8RyzaSctPMt8EmxMcMY69LxgMPCrkjvQMpoHrlvYhuAFkXVD-ArgBX2X0lbc9tHIlzFBIvKurCzn0MSnXFSndiZe9UCIAbkGaLaC1JePxi4j rP27-45Ej51YZAPjsjX7TCq6T9pv4WuMBXZjd7xP5d.aM0eZM6L4NtBKDU8JSnL-'
Overwrite free disk space /home/minty 0
[Errno 13] Permission denied: '/root/tmp9rezCf-S2MbeycUqCLTxlnxy8Q_DBb0EQ9epScnwm7p 59aa9SKWQUCUK9RgAClQIDoAzLlc.bvR8hg5lLVibsMrQKiYM2VzNoPvwGDf8AoxsVcbZER lxcGzEE1UXJ.vJu1RRrS9MYKEi18UVz99vjwJ6.ZpipaJQcTH1.aW6rvOkHYXcR 4OTuJJ2EqxwLH-qW9MrC2WB9qNP4exUzJgp.V jecVmx.zyHIbcn06.z.an1xYUDJWpoFeE'
[Errno 13] Permission denied: '/run/tmp_MpqY4d9jSQDuAbPEfRZ1VOmB4hKQWPr841cYp71BwFF0bdzTdTSzJbcMJ62xXBCfb 9zMMhh.DjUm-NsQLoQLVdI54X66L6sVqkhr5pdT-Q-T6nGfLM-.DGEud GVYhOlITIGF_Uh1uAa2mKxJZ-PgCTDgxGeUQRJgtaWZ7KR 5HOtWYMRr_fYSCiOjCXjgIhlvFypdJ5XMGydC5oAnla3xxm-68mZ3CX-lYC6i.HZ_tShsJ._aYZa9MQ8'
[Errno 13] Permission denied: '/dev/tmpGjZ2cobAsZ8IPDGSk2y.Hu7aL-KOquH6VIaP72_T3VkYvao5PBceKu6puu7o.qmHlZhv7e6BC2uZvGK4Nmer.4dJHxV5NVzm5dfGflR4ZgeEKsiRm0dJlKi YZWbbD-qw3ek0NFSM_DmrRwZR7Q0.ax_xg1hZt9o9s.rlNex4.TF-RaSt-hu5XOlln.aiIGrEYRET1Cfh6kIWrK9Bq0IO3O9GLBx3-t5mcst8oryYv4wrMW4lCWXsa JU0P'
Overwrite free disk space /run/lock 0
Disk space recovered: 0
Files deleted: 0
Special operations: 12
Errors: 5

for regular user bleachbit my folders in the edit-permissions-drives tab are as follows
/home
/home/"myuserdir"

in the gui here are errors for running as a user not root
E: Could not open lock file /var/cache/apt/archives/lock - open (13: Permission denied)
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
no such table: icon_mapping: /home/myuserdir/.config/chromium/Default/Favicons
Delete 4.1kB /home/myuserdir/.bash_history
[Errno 13] Permission denied: '/home/tmpIumsrC1t yoZuLhpl2BSidPDk3uZMOwIskVCSuVFT-2O1vpiPmOoGhtwpzTvE69Z7_An.xFv5ia8GcQj4fCDsBkxEb0OoqG8FXb1k7xWhgpsdi4U1frH.TPNRkoB97vpRq0mryzmkkzJvu91ljm_RM7bTLmztaF.AxB1H5VQesGKEi-EsGV1JZuUgxS-G81Ex FIhVlVBP-ZII4Y9Hz15usXP8AYHKk-YnX5zaxhivQzlCERgWS_CPLtJ_E'
Overwrite free disk space /home/minty 0
Disk space recovered: 16.1MB
Files deleted: 1176
Special operations: 23
Errors: 4

I had a thread going on linuquestions.org on this same issue and here is a post from someone who is able to duplicate this issue of data not being wiped in bkeachbit. I'll paste his results below.

#7
jcgrin
LQ Newbie

Registered: Mar 2007
Posts: 3

Rep:
Here's what I was able to duplicate on another machine, using three junk ten meg files. Test one I allowed BleachBit to remove the files, and over-write the cleaned space, foremost was able to recover two of the files and a partial of the third. Test two I allowed Blechbit to run, and clean the space, and then ran it again, foremost was unable to recover any files. Test three, four, five, and six, I erased the files via the trashcan and then ran bleachbit in the first two tests Formost recovered all three files, in the fifth test no files were recovered, and in the sixt test only a single file was partially recovered. It seems like Bleachbit is doing it's job most of the time, but for some reason there are circumstances in which it doesn't, or in which the job is not complete. An associate of mine suggests that there may be something holding onto the data for whatever reason and the fact that Bleachbit can't touch it generates an obscure Bleachbit Error that may or may not show up depending on configuration. As an interesting item of note, in no test was bleachbit able to recover the complete thirty megs at once only after running it multiple times. This was run on a Ubunto 12.04LTS server box with a KDE desktop environment. Other flavors and configurations may yeild different results.

I will try that this weekend you solution. Unfortunately I can't test on the same files as before as I managed to get rid of them with dd. The 5% thing for me might be higher because when I used dd the "overwrite" file was 56GB and the OS reported free space as 49GB before and after the "overwrite" file was created. So you can see a little more than 5% roughly 10% actually was not being reported yet was actually there.
I will also share your solution in y other thread to see if it's a universal solution. Thanks for your work though and look forward to the final resolution but I will try this in the meantime. If not. Always know dd will work

It is supposed to do more things Like clean temps, caches ect... but I think i Showed it does not do what dd does in regards to writing random data or zero data to disk so on that I beg to differ. Bleachbit does not write data to ALL the unallocated space on a partition and dd does so thats a huge difference. Who cares about file names if files are not being overwritten on 5-10% of the free space or are recoverable even when overwiting on a per file basis or on a partition wide wipe. I would rather have every bit overwritten and that's what dd does well and bleachbit doesn't do well. Did you see my earlier post below regarding this thread also being on bleachbits support forum. They even said they also see that there is a shortcoming and are fixing it and offered a tmp fix in the meantime. I would use bleachbit to clear the space and dd to securely wipe the cleared data and use shred and the rm to get rid of dd's overwrite file. This is what I found has made nothing recoverable in foremost and no other method.

We did miscommunicate I thought you were someone else commenting about prior to the fix. My bad. I will try what you said. Out of curiosity why was bleach bit limited prior to the fix even as root. Just curious. If its too much to explain don't worry about it. Thanks for your work. I did post your fix on the other thread a cpl days ago.

This should be my last question. I put the FileUtilities.py file in the right spot but I'm not a programmer so excuse a stupid question here. Don't I need to compile this to replace the FileUtilities.pyc file. If so HOW do I do this and with which version of python do I do it with.
Also if I go to the directory with bleachbit.py and launch it using "python bleacbit.py" i get the same "version". How do I launch regular user or root user versions this way. They seem to launch the same one whether I use nothing, sudo or gksu prior to that command. I notice it launches root and regular version if I just use "bleachbit" at terminal prompt or "sudo bleachbit" but it doesn't with the full python command from the directory with the bleachbit.py . No biggy just wondering why or what mechanism launches the root/regular versions when invoking from python itself

Well I tried it with the new .py file and I believe it is still flawed and also had some unintended consequences. Here is my experience with it. First it is not cleaning itself up and every time I run bleachbit now I lose HDD space. I found it was creating these large tmp files that look like this. But not just in /home either.
'/home/tmpge6oTk0a beyfHekUi8EaQQ3kfPlfO99yb4wrPUgYNZS085vDbs4bVr7fZYn6vRyRpivb7CzchkxOz8RyzaSctPMt8EmxMcMY69LxgMPCrkjvQMpoHrlvYhuAFkXVD-ArgBX2X0lbc9tHIlzFBIvKurCzn0MSnXFSndiZe9UCIAbkGaLaC1JePxi4j rP27-45Ej51YZAPjsjX7TCq6T9pv4WuMBXZjd7xP5d.aM0eZM6L4NtBKDU8JSnL-'

After deleting these files as root I get my space back that I had before running bleachbit with the new .py file. If I run bleach bit again it creates them again and leaves them on my hdd. They are 100-250MB each and there is like 5 of them. I don't claim to have any idea about fsync ect... but is it possible it's dumping after it cleans but before it wipes.
Another issue in regards to fixing the original problem. I didn't go through a real test because I used a script that streams the output of df while either dd or bleachbit is running. Here is what I see. The original df -h shows 140G total space, 95G used, 38G available. As you see this is 7G short of total space which we know happens. Here is what shows while I run my script during dd. The avail space eventually says 0G and the used space will be 133G. There is the 7G we talked about. dd will keep growing the used column till it reaches 140G but when I use this script with bleachbit it stops when avail=0G and leave the used column at 133G thus not writing over the 7G in question. I don't know how to program so i can't tell you the problem with how bleachbit is written but on the surface it appears to use the info in space available column to determined when it's done. What it needs to do is take the difference between total_partition_size and used_space to determine when its done for example use an if statement like "if used_size=total_size then; done". Of course that is just the idea not the code. As you see from this test there was no need to proceed to your suggested test since clearly all the unallocated disk space is not being written to by wipe in bleachbit.
After that don't forget to address the other new issue with it writing stuff to disk. Somehow this resulted from the fix since the old .py script leaves me with more space on my disk and the new .py file leaves me with less.
I feel like I'm being a pain in the ass. If I am let me know and close the thread. If this is helping I'll be happy to keep testing fixes and reporting what I find since ultimately I like bleachbit in theory and it has only the one flaw besides the second one that was created by the fix.