Using Ununtu 12.04, and recently got a message that disk space is running out. Ran the Disk Usage Analyzer, which froze. After some research, I see a directory in ~ called "9fybsyiikg" which is 1065357312 bytes.

I tried opening that folder in the file manager, and nothing happens. I tried lsing in, and nothing happens.

And then I tried rm -rf 9fybsyiikg, and nothing happens.

Any ideas what this directory may be, and how to get rid of it?

  • AFAIK, There's a file limit for rm to operate. If that is above the limit, then rm will display error. BTW, try whether ls -l | more lists it?? – AzkerM Mar 17 '14 at 16:22
  • This sounds like something is seriously messing up your system... – w4etwetewtwet Mar 17 '14 at 16:22
  • 1
    @AzkerM the limit you are thinking of is ARG_MAX (see here) and it shouldn't apply here unless the OP is trying rm ~/9fybsyiikg/* – terdon Mar 17 '14 at 16:30
  • 1
    @Rmano why are symlinks relevant? The OP is attempting to rm -r the directory, everything in it (including symlinks, but not their targets) will be deleted. – terdon Mar 17 '14 at 16:44
  • 2
    @AzkerM no need for xargs there! Especially not that way, it will break on any weird file names. On GNU systems, use find -delete, or -exec rm {} +. If you really want to use xargs do it like this: find -print0 | xargs -0 -I {} rm -rf. – terdon Mar 17 '14 at 17:26

The rm command will take some time, if you're not getting any errors, just let it run. If you do get errors, try some of these solutions:

  1. find

    find ~/ -maxdepth 1 -name 9fybsyiikg -delete
  2. rm and wait, this might take a while (yes, I know you tried it but it might help others)

    rm -rf ~/9fybsyiikg
  3. You might just have too many files, try this

    find  ~/9fybsyiikg -delete && rmdir ~/9fybsyiikg
  4. If all else fails, use some Perl magic:

    perl -e 'use File::Path; rmtree "$ARGV[0]"' ~/9fybsyiikg


    • -e : run the script passed on the command line

    • rmtree : a command from the File::PAth module that deletes whole directory trees

  • If I understood correctly and the problem is the BleachBit ones (as it seems) --- that program created a file for every little available space on the disk to overwrite it and the delete it for security reason. It probably crashed in the middle and left back millions of tiny files mapped all over the disk in that directory... so it is basically an exercise in patience ;-). It is even almost impossible to ls of find it, given the size... – Rmano Mar 17 '14 at 16:34
  • @terdon why would perl or find be faster than rm? This guy is pretty convincing: askubuntu.com/a/114970/334825... – Ohad Schneider Feb 24 '17 at 17:16
  • 1
    @OhadSchneider I was thinking of cases where rm was failing (I guess?). To tell you the truth, 3 years down the line, that comment doesn't make much sense to me either. I can't honestly say I remember what I was thinking of and it does seem like I was just wrong, so I'll delete. Thanks. – terdon Feb 24 '17 at 17:36
  • @terdon I can totally relate, when I read some of my posts from a few years back I think "who is that idiot" :) IMHO you should just delete options (3) and (4) above from your post, as they seem to suggest those might work in cases where rm -rf doesn't (specifically when a folder contains too may files) and I did not encounter any evidence to support that (including recent personal experience, unfortunately). – Ohad Schneider Feb 25 '17 at 13:21
  • Ah, no I wasn't that wrong ;) Both 3 and 4 nicely avoid the ARG_MAX problem. Think of them as alternatives to rm foo/* not rm - rf foo. – terdon Feb 25 '17 at 13:28

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