Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like to create a "/dev/null" directory (or a "blackhole" directory) such that any files written to it are not really written, but just disappear.

I have an application that writes out large temporary files to a directory. I have no control over the name of the files and I don't really care about the content of these files. I could write a script that periodically clobbers these files, but the files are written out very quickly and fill my disk. I'm looking for something cleverer. I want the application to "think" that it is writing out these files, when in fact, the writes are just being discarded at the other end.

Also see this old related thread.

share|improve this question
It sounds like FUSE might be an option: kerneltrap.org/mailarchive/linux-kernel/2008/2/15/868564/thread – Stefan Lasiewski Mar 16 '11 at 20:32
i just asked myself the same question, and used the same name for the directory i failed to create. – ixtmixilix Mar 3 '13 at 6:56
up vote 30 down vote accepted

This isn't supported out-of-the-box on any unix I know, but you can do pretty much anything with FUSE. There's at least one implementation of nullfs¹, a filesystem where every file exists and behaves like /dev/null (this isn't the only implementation I've ever seen).

¹ Not to be confused with the *BSD nullfs, which is analogous to bindfs.

share|improve this answer
Fantastic - I've used this as part of an answer on SO – Phil Lello May 5 '11 at 21:52
a note to people who end up with compile errors on that program: g++ -Wall -o nullfs nullfs.c++ `pkg-config fuse --cflags --libs` worked for me. – ixtmixilix Mar 3 '13 at 7:11

Another approach would be a LD_PRELOAD wrapper; basically a small shared library which is loaded before libc.so, and intercepts calls to "open" with something that checks the prospective file path and substitutes "/dev/null" if it would be in the target directory.

This has the advantage of being (a) entirely in user-space - no kernel hacking required; and (b) only affecting the single errant application.

A simple example is at http://www.noah.org/wiki/LD_PRELOAD_notes, but in your case you will want to intercept the "open" & "creat" system calls.

share|improve this answer
...assuming the application does system calls via libc, not directly via int 0x80/syscall/sysenter/whatever else. – Ruslan Feb 7 at 18:44

If the program is so stupid to not let you switch those logs off, may be it also doesn't check for errors after opening a log file? I'd try mounting some dummy read-only file system (e.g. using mount -o loop.)

share|improve this answer
this approach doesn't work unfortunately. The application dies if it can't write to this file. – dogbane Mar 16 '11 at 12:22

You say that removing the files periodically with a script isn't fast enough. Could you live with a trigger that deletes a temporary file any time your application finishes writing and closes it? If so, you might make use of the "inotify" API.

(See http://en.wikipedia.org/wiki/Inotify and https://github.com/rvoicilas/inotify-tools/wiki/)

share|improve this answer

Just symlink that directory to /dev/null

rm -rf ~/.logs
ln -s /dev/null ~/.logs

/dev/null, doesn't have to be a directory. If the program tries writing to ~/.logs/log1.dump, it still goes right into /dev/null.
I do this for Google Chrome's cache because after a while it gets so big that Chrome will take minutes to start.

share|improve this answer
This wouldn't work because symlinks are files, not directories. Trying echo hello > ~/.logs/log1.dump gives ~/.logs/log1.dump: Not a directory. However, echo hello > ~/.logs works because .logs is a file. – dogbane Mar 16 '11 at 13:25
You must be kidding us. $ ln -s /dev/null dev-null; touch dev-null/zzz gives me touch: cannot touch 'dev-null/zzz': Not a directory – alex Mar 16 '11 at 13:28
Like I said, it works for Chrome. It prevents it from writing into the cache. If it causes the asker's program to crash, then obviously it doesn't check if file pointers are NULL. – jonescb Mar 16 '11 at 13:54
It probably means that Chrome skips writing if there is an error opening the file. You could achieve the same effect by removing write permission from the dump file or the directory its writing in. – KeithB Mar 16 '11 at 14:04
True, changing the permissions of the directory would probably make more sense. – jonescb Mar 16 '11 at 14:53

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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