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.save, then truncate
In this scenario, IF the file is not opened by
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 :
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.
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