The answer depends a bit on what file.txt
is, and how process write to it!
I'll cite a common use case : you have a growing logfile called file.txt
, and want to rotate it.
Therefore you copy, for example, file.txt
into file.txt.save
, then truncate file.txt
.
In this scenario, IF the file is not opened by another_process
(ex: another_process
could be a program outputting to that file, for example a program logging something), then your 2 proposals are equivalent, and both work well (but the 2nd is prefered as the first "cat /dev/null > file.txt" is a Useless Use of Cat and also opens and reads /dev/null).
But the real trouble would be if the other_process
is still active, and still has an open handle going to the file.txt.
Then, 2 main cases arise, depending on how other process
opened the file :
If other_process
opens it in the normal way, then the handle will be still pointing to the former location in the file, for example at offset 1200 bytes. The next write will therefore start at offset 1200, and thus you'll have again a file of 1200bytes (+ whatever other_process wrote), with 1200 leading null characters! Not what you want, I presume.
If other_process
opened file.txt
in "append mode", then each time it writes, the pointer will actively seek to the end of the file. Therefore, when you truncate it, it will "seek" until byte 0, and you won't have the bad side effect! This is what you want (... usually!)
Note that this means you need, when you truncate a file, to make sure that all other_process
still writing to that location have opened it in the "append" mode. Otherwise you'll need to stop those other_process
, and start them again, so they start pointing at the beginning of the file instead of the former location.
References : https://stackoverflow.com/a/16720582/1841533 for a cleaner explanation, and a nice short example of difference between normal and append mode logging at https://stackoverflow.com/a/984761/1841533