A folder was created in my home folder (not by anyone), and I cannot see the folder contents. She has root privileges, but when the nautilus root access the folder is empty. When I try to remove it, it will appear to remove more than 1 million files from my computer, and I do not know what these files are.

How i can see these files? the name of folder created is "4F8ZBREShQ". I'm scared about it...

  • Open a terminal, run the command ls -ld 4F8ZBREShQ and coypy-paste the output into your question. In case there are non-printable characters in the name: if this tells you “No such file or directory”, run ls -lA and copy-paste the line corresponding to this file. I may have other questions depending on the output. – Gilles 'SO- stop being evil' Feb 28 '14 at 19:44
  • Hi Gilles, it's the output: drwxr-xr-x 2 root root 262000640 Fev 24 22:56 4F8ZBREShQ – user68624 Feb 28 '14 at 19:53
  • 1
    Ok, so you can see the content of the directory, but it contains millions of files, and it's probably a Nautilus bug that's causing it to appear empty. Run the command ls -lU 4F8ZBREShQ | head -n 30 to see the names of a few files in that directory. Has your computer crashed recently (especially around Feb 24 22:56)? – Gilles 'SO- stop being evil' Feb 28 '14 at 19:57
  • 2
    @Wilf It's the directory's modification time. Showing a directory as empty when it isn't is hardly user-friendly either. – Gilles 'SO- stop being evil' Feb 28 '14 at 20:02
  • 3
    @Gilles OK, Bleach Bit is the common bit between this report and askubuntu.com/questions/424307/… . Bug? (Never used this thing, first time I see mentioned). Some user should report this to their bug tracker... – Rmano Feb 28 '14 at 20:07

Short answer: do

rm -r 4F8ZBREShQ

and go for a walk or get yourself a coffee.

Long answer:

Seems a bug of BleachBit. See http://bleachbit.sourceforge.net/forum/unremovable-folder-after-trying-wipe-free-space; you can join the discussion there.

The OP of Not able to delete folder from gui or terminal has been able to get rid of it, see the answer; but probably his method is overkill.

In effect, doing a rm -r 4F8ZBREShQ and being patient (really really patient; ext4 is not a speed monster for large directories, and this is LARGE) would work.

Recent ext4 should use a linear time with the size of the directory for the deletion process; even then, deleting millions of files will require a considerable time --- from tens of minutes to several hours.

  • I run the command : "rm -rf 4F8ZBREShQ" and after 30 minutes, the folder finally is removed. Thank you everyone, it's solved my problem. – user68624 Feb 28 '14 at 21:01
  • BleachBit version 1.1 should no longer leave these files behind. These are related to "wipe free disk space" option – Andrew Mar 23 '14 at 15:21
  • I installed BleachBit version 1.0 and have same problem. – PHP Learner Apr 28 '14 at 12:01
  • 1
    @PHPLearner I am hoping to soon release BleachBit version 1.1. For now, I noted the issue in the BleachBit 1.0 release notes. The time required to rm the temporary directory depends on the number of files, disk speed, etc., but 24 hours does seem slow. You can check progress by checking how many free inodes are available on the file system (df -i). – Andrew Apr 28 '14 at 21:34
  • 1
    For the impatient, doing a watch -n 5 'df | grep sda2' really helps see how the rm is chewing its way through the files.. Replace sda2 with your specific device name. – Sandeep Deb Jul 20 '17 at 20:41

That file you are referring to is probably just a file full of zeros or random data that bleachbit uses to wipe free space. If bleachbit fails or is turned off before wiping is complete the huge file remains. It is safe to run the command "rm -rf" A similar thing will happen when you overwrite free space manually using the "dd" command. "dd if=/dev/zero of=/user/sloshnmosh/Desktop/junkfile bs=4k conv=notrunc" after all space is overwritten you would issue the command "rm /user/sloshnmosh/Desktop/junkfile" Bleachbit was simply shut off unexpectedly before being able to issue the "rm" command leaving all the zeros or /dev/urandom data that was used to occupy (overwrite) disk free space.


I was dealing with the same problem and the solution was to run in terminal rm -r "folder_name" and wait until is done.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.