Re: rm app.log? No problem
On Wed, 17 Feb 2010 00:40:07 -0800, dmcreyno wrote:
Being a J2EE web developer for the bulk of my career, I've not been
called upon too often to do basic Java file IO. Here's what I am doing.
1. Open a file writer.
2. Write a few strings to the file.
3. Put the thread to sleep.
4. While the thread is asleep, use "rm" on the command line to delete
the file.
5. Thread wakes up and writes a few more strings to the deleted file.
6. Program exits cleanly despite the fact that "ls" confirms, there is
no file.
WTF?
That's the required behaviour on UNIX/Linux. Actually all 'ls' does is
confirm that there is no filesystem entry in the directory, the file and
its contents still exist.
When you 'rm' a file which is open the file doesn't actually go away. All
that gets removed at that time is the entry in the directory containing
the file. The actual contents of the file remain until *all* open file
descriptors for that file are closed.
This feature is actually used as a common way of implementing temporary
files - a process creates a file, opens it and then unlinks it. The
process can then read/write that file, and when the process exits the
file contents go away. Also, since there is no filesystem entry for it no
other process can accidentally access it. [It's not perfect as the creat/
open/unlink are not atomic, so there's potential for conflict and another
process could access the file during that very small window.]
It also causes a common concern in sys. admin. when a disk fills up. Even
though a very large file is deleted the disk space is not recovered if
that file is still open (very often the log file from a runaway process).
It's also necessary to identify the process which has that file open and
kill it, and that task is made more difficult once the filesystem entry
has been removed.
--
Nigel Wade