I just came across the advice that if you want to get rid of a large file and a process has the file handle open you should copy it to /dev/null and its size will be reduce to zero.

How does this work? Or does this even work?

After a quick search I found conflicting answers ranging from "Yes, this totally works" to " Your whole machine is going to blow up". Can somebody enlighten me?

I found the question here: https://syedali.net/engineer-interview-questions/

closed as off-topic by Eric Renouf, Archemar, don_crissti, terdon Aug 22 '16 at 16:01

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Eric Renouf, Archemar, don_crissti, terdon
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    Where did you find the advice? I can't see how doing cp big_file /dev/null would modify big_file in any way (well, perhaps its atime), and especially not how it would 0 out the file – Eric Renouf Aug 22 '16 at 13:47
  • I found it in this blog about potential interview questions: syedali.net/engineer-interview-questions – user2393256 Aug 22 '16 at 14:18
  • 1
    Ah, note that you got the direction of copying wrong, that page says "you can ‘cp /dev/null’ on the file" which is the opposite of copying your file to /dev/null – Eric Renouf Aug 22 '16 at 14:21
  • 1
    Ah, true i got that wrong. That makes more sense. So nevermind my question and thanks for helping :) – user2393256 Aug 22 '16 at 14:22

You misread the advice, the idea is not to copy the large file to /dev/null, which wouldn't affect it in any way, outside putting it in cache if space is available.

cp bigfile /dev/null # useless

The advice is not to remove the file then copy /dev/null to it, as it would keep the original inode unchanged and won't free any disk space as long as processes have that file open.

The advice is to replace the file content with /dev/null one, which, given the fact /dev/null size is zero by design, is effectively truncating the file to zero bytes:

cp /dev/null bigfile # works

cat /dev/null > bigfile # works

It might be noted that if you use a shell to run these commands, there is no need to use /dev/null, a simple empty redirection will have the same effect and would be more efficient, cat /dev/null being a no-op anyway.

: > bigfile # better

> bigfile  # even better if the shell used supports it

Short answer is no, it doesn't work.

There are many flavour of unix abroad, may be for some this might work, can you provide a link ?

Now, you can test it:

  1. open two terminal in your system.
  2. copy to non root user a large file (like /var/log/messages )
  3. vi it ( vi messages ) in first terminal.
  4. cp messages /dev/null on other.
  5. quit vi on first.

messages should still be there.

(vi is not a good candidate, if you remove file, (rm messages) file will be removed (at least on ubuntu 16.04), you can rewrite it from vi (using w but file will be read from .messages.swp on current dir)

  • No, cp messages /dev/null cannot possibly truncate messages. (Well, sure, it's physically possible, but if a system erases data when told to copy it, it's severely broken.) – Gilles Aug 22 '16 at 22:28

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