bleachbit wipe free disk space doesn't work


Personally I have used bleachbit for a long time and just assumed it worked well given all the recommendations I've seen for it. I know how to use it in root and as a user and actually run it fairly often. Today I ran onto an issue on a doc that libre office couldn't open because it was corrupted. I needed this document for school so trying everything I ran foremost from the command line to see if I could recover an older version. Given my use of bleach bit I thought this was a lost cause but to my surprise a ton of documents were recovered. After seeing this I ran it on avi and jpg files and again it recovered them. I'm here to say the bleachbit free-disk wipe feature does not work based on these results.
Does it matter what folder I put in the drives tab for where to write data to or something. I get no errors so I assumed it was working but its obviously not. Also I read I can choose drives and partitions besides the active one as long as they are mounted but I don't see where to pick the drives to do this to. Under drives in preferences it says choose a folder for each drive but where do I select the drive to apply to that folder. Anyway help would be aprreciated

In my tests of several file system types (ext3, ntfs, etc.) even a small signature (about 10 bytes) could not be recovered, so let's make sure you are wiping the write partitions.

It matters very much which folders you select. For every partition you want to wipe, you must choose one writable folder. On Linux in the command line run df -h to see a list of mounted partitions. On my system it looks like this:

$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 716M 0 716M 0% /dev
tmpfs 724M 144K 724M 1% /dev/shm
tmpfs 724M 636K 724M 1% /run
/dev/sda3 15G 8.9G 5.3G 63% /
tmpfs 724M 0 724M 0% /sys/fs/cgroup
tmpfs 724M 0 724M 0% /medi
/dev/sda6 417G 286G 110G 73% /home

Based on the size, you can see / and /home are my main partitions. Cleaning /home is usually enough for personal documents, so I can configure BleachBit to clean any subdirectory such as /home/username.

You can tell it is working because it takes a long time---roughly 5-60 minutes depending on how much free space, speed of hardware, etc.

Try that and let me know how it works. If it does not, please send the list of mounted partitions and the paths you wiped.

Andrew, lead developer

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.

What command line are you using for foremost? What is the output of df -h?

Taking 30 minutes implies it wiped the free disk space of at least one partition but that doesn't mean it cleaned all of them.

So if I'm running bleach bit and select /home does that mean its gonna clean that folder and its subdirectories.

Yes and no. Specifically BleachBit is wiping the free disk space of the partition, which typically includes the 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.

In the Preferences you can add any folder you want.

Andrew, lead developer

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

Which file system do you use (ext3, ext4, btfs)? Linux kernel version? Maybe you could verify the file system covers the whole partition?

If /dev/sda2 is mounted on /home and nothing else is mounted under /home, then wiping one folder under /home should be sufficient.

When you wipe free disk space, run BleachBit from the console to check for any error messages that may not show up in the GUI. It is also helpful to monitor the free disk space (using gnome-system-monitor or similar) to verify /home gets to 0% free.

This week I will do some more research and try to replicate this. I have automated scripts for checking something very similar (except not using blkls or foremost), and I've been thinking about cleaning them up and publishing them with the rest of BleachBit's unit tests. This will be a good opportunity to work on that.

Andrew, lead developer

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
***( 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

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 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.

LQ Newbie

Registered: Mar 2007
Posts: 3

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.

Those "permission denied" errors are not important for the data remanence issue.

I developed an (automated) unit test, found the method in BleachBit version 0.9.5 was not completely effective, and improved it. There is still more work to do, but the changes so far may solve your problem.

For now you can test it yourself by overwriting with revision 2885 from SVN. If you installed BleachBit from a repo or .deb file, this file goes somewhere in /usr (do a search for Let me know how it goes.

Wiping free disk space is most effective as root because, by default, file systems such as ext3 and ext4 reserved 5% of the space for privileged accounts. If all the space is consumed, the log in the terminal should look like this:

note: wrote 119 files and 3619840 bytes in 196 seconds at 0.02 MB/s
note: 0 bytes available to non-super-user
note: 0 bytes available to super-user

As you can see, right now it is rather slow because it calls fsync to flush to the disk.

Andrew, lead developer

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

BleachBit should be more thorough than dd. After doing the equivalent of dd to fill the disk to erase remanence of deleted file contents, BleachBit creates empty files with long filenames to erase remanence of deleted file names. However, this last part is now rather slow, so I am looking for a way to make it faster.

Andrew, lead developer

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.

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.

We miscommunicated. I mean with the enhancements I posted in this thread, BleachBit's improved "wipe free disk space" should do more than dd. Deleting temporary files and cache is a separate issue.

files are not being overwritten on 5-10% of the free space

This is a limit imposed by Linux. When BleachBit or dd runs as a non-super-user, then both have this limit. When they run as root, they don't have this limit.

Unfortunately I can't test on the same files as before as I managed to get rid of them with dd.

You can quickly dirty your drive using a Bash script like this

for i in $(seq 100); do echo $i; cp /home/user/source.jpg ~/target$i.jpg;done

To use this, change 100 to how many copies you want to make. Then change /home/user/source.jpg to an image you want to copy. After it's done run

rm -f ~/target*.jpg and run Bleachbit

Andrew, lead developer

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.

I made several changes, and I think the biggest was calling fsync, which flushes buffers to disk, in addition to flush, which flushes the buffer from the application to the operating system. I assumed fsync was implied, and sometimes it is: that explains why the results were inconsistent.

Andrew, lead developer

This should be my last question. I put the 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 and launch it using "python" 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 . 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.

BleachBit is not good a secure delete! Before anyone asks if I selected the right options, Yes I did! I know how to use the program. Anyway! Back to my explanation: I made 4 custom files to test. I shredded them and they were deleted "supposedly". I also did a drive wipe using the same bleach settings. And after all of that I was still able to recover all 4 custom files! I tested it again and again. And I got the same result each time. It also never erases browser history regardless of selecting the option! Honestly bleachbit is a worthless program. People are best off just deleting files manually and using terminal to overwrite files and free space. In a day of hackers this is info people need to know!

George, I replied to you in the other thread. In summary, I would like as a next step some more information from you to reproduce the situation on my system, and then I will work to either clarify expectations or fix any bugs.

Andrew, lead developer