It's up to the file system driver to actually free the allocated space, and that will usually happen only once all file descriptors referring to that file are released. So you can't really reclaim the space, unless you make the application close the file. Which means either terminating it or playing with it "a bit" in a debugger (or you could hack the kernel, but would advise against that).

The rationale behind this behaviour is that the kernel wouldn't know what to do with data requests (both read and write, but reading is actually more critical) targeting such a file.

It's up to the file system driver to actually free the allocated space, and that will usually happen only once all file descriptors referring to that file are released. So you can't really reclaim the space, unless you make the application close the file. Which means either terminating it or playing with it "a bit" in a debugger (e.g. closing the file and making sure it is not opened/written to again, or opening /dev/null instead). Or you could hack the kernel, but I would advise against that.

Truncating the file as Stephane suggests might help, but the real outcome will also depend on your file system (for example pre-allocated blocks will likely be freed only after you close the file in any case).

The rationale behind this behaviour is that the kernel wouldn't know what to do with data requests (both read and write, but reading is actually more critical) targeting such a file.