Server Fault is a question and answer site for system and network administrators. 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

In order to run some tests, I need to run an app that will delete a file

Since it's expensive for me to recreate this file (>40 GBs) every time I need to run another test, I want to mock the deletion of this file.

But this must be completly transparent to the app deleting it. That means creating a symlink is not an ok solution ([ -L symlink ] returns 0 while [ -L file ] returns 1, so this wouldn't be completly transparent for the app).

share|improve this question
anyone know about unionfs? seems it might help, but I never worked with it – Lem0n Mar 23 '13 at 5:21
up vote 6 down vote accepted

There are several solutions. dd like solution may take some time, however using seek

dd of=mybigfile bs=1 count=0 seek=40G

is instant. however the 40g space taken by the command is not seen in df...

So the best is probably

fallocate -l 40g mybigfile

that creates instantly mybigfile and the space is actually reserved from the FS (and is seen in df)

-- edit after comment --

What about a hard link

cd data 
make 40g file "myfile"

then for each test

cd ../test 
ln ../data/myfile testfile

command to unlink testfile

data and test dirs being on the same FS (different dirs to prevent mistakes etc..).

The hard link status is pretty transparent and is not likely to be tested by the application . The unlink operation will remove the name associated with the inode and then decrement the links counter in the inode, and should be very fast (the file and its data will be actually freed only when the inode counter goes down to zero - which will not happen unless you unlink also data/myfile).

share|improve this answer
I didn't know fallocate. Pretty cool. But unfortunatelly it doesn't solve my problem because the content of the file is important (there's a check before it's deleted) – Lem0n Mar 23 '13 at 5:17
Hard links seem like the ideal solution here. – Michael Hampton Mar 23 '13 at 5:34

Use a filesystem that supports snapshots. ZFS and btrfs come to mind. Just take a snap with the file present, and then restore that snapshot after each test.

Both of these filesystems take snapshots in such a way that restoring should be very fast.

share|improve this answer
yes, I guess that works. Can you think on something that doesn't require a filesystem change? Maybe hooking the remove-file syscall with a kernel module or something? – Lem0n Mar 23 '13 at 5:22
Nope, can't think of anything else. Honestly, this would likely be much faster to implement than some kernel hack... – EEAA Mar 23 '13 at 5:30

For things like this, I prefer to use an LD_PRELOAD trick. Write a tiny C library that mocks unlink (and maybe stat64 if the test also checks for file existence) and preload it. Test it on a less important file :)

share|improve this answer

Simple: Create a hard link to the file to be deleted, like ln original /some/where/safe. Go ahead and blow away the file, it won't be gone (just the link, which you can recreate any time).

share|improve this answer

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.