story time:

i actually had a situation recently where i wanted to delete a file that a process had open because i needed to free up space.

i had a process that wrote a massive log file (200GB) filling up the disk. i didn't want to kill or restart the process, but i needed to remove the log somehow. there was no log rotating option without killing the process. and i knew that just removing the file would not work, so instead i did "echo -n > logfile" causing the file to be truncated.

since the process still had the file open for writing it kept writing to the position it had written to last, creating a 200GB sparse block of virtual zeroes. not exactly what i wanted, but in hindsight, not surprising, and it did solve the problem of freeing up 200GB of space.

except this morning, a few weeks after i truncated the file the space was gone again, and the file was now 400GB large. how did those 200GB come back? and where even did they come from? it is not another sparse block, it actually has data (maybe junk data, but not all zero)

it is unlikely that the process wrote 200GB of logs in two weeks. the other 200GB were written over 2 years. i have yet to analyze what that data is. so far i only confirmed that it isn't all zero (by using cp --sparse=always, ensuring that all zero blocks would be made sparse which would then be easy to detect) (further cursory inspection suggests that the process did in fact write 200GB of logs in two weeks. the error being "Failed to bind socket". i wonder if that was caused by the disk being full the first time around.)

TL;DR: if you need to free up space from a file opened by another process then truncating works, but beware of side effects.