4

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

Rmano
  • 31,947
user68624
  • 115
  • 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
  • @Gilles - loading a folder with 2 million files would not be very file manager friendly... Why the specific date & time? – Wilf Feb 28 '14 at 20:00
  • 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
  • This is the second time I see this here... http://askubuntu.com/questions/424307/not-able-to-delete-folder-from-gui-or-terminal / maybe some program is going crazy? – Rmano Feb 28 '14 at 20:04
  • Gilles, nothing happen when i run "ls -lU 4F8ZBREShQ | head -n 30" But I remember that my computer crashed a few days ago, when I used Bleach Bit to cleaning, and i force shutdown. – user68624 Feb 28 '14 at 20:05
  • 3
    @Gilles OK, Bleach Bit is the common bit between this report and http://askubuntu.com/questions/424307/not-able-to-delete-folder-from-gui-or-terminal . 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

3 Answers3

10

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.

Community
  • 1
Rmano
  • 31,947
  • 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
  • @Andrew But version 1.1 is not available for download in BleachBit website!!! – PHP Learner Apr 28 '14 at 17:44
  • @Rmano sudo rm -rfv XTJHIFwdSb did not return anythings and did not finish after 24 hours and no success after stopping it by Ctrl+C. Anyother suggestion? – PHP Learner Apr 28 '14 at 17:56
  • @PHPLearner are you sure BleachBit is stopped? This is quite strange. How big is that directory? Leave out the v and be sure you have not any alias on rm. Otherwise you can explore here: http://askubuntu.com/questions/114969/is-there-any-faster-way-to-remove-a-directory-than-rm-rf – Rmano Apr 28 '14 at 18:02
  • 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
  • @Andrew Thank you, I used df -i and it seems that speed of rm -rf XTJHIFwdSb is about 20 inodes per second. There is about 1.5 Millions inode in XTJHIFwdSb folder. so it takes about 20 hours to finish! – PHP Learner Apr 29 '14 at 07:59
  • BleachBit 1.1 is released – Andrew May 17 '14 at 14:41
  • I had similar problem after bleachbit created strange folder in my system and rm -rf talking long time. I moved the folder to trash directly instead of deleting (using nemo) and then emptying trash. This solved the problem for me. –  Dec 10 '14 at 07:27
  • 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
0

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.

sloshnmosh
  • 1
-1

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

George O.
  • 39