Re: rm app.log? No problem
On Wed, 17 Feb 2010 11:23:55 -0500, Lew wrote:
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?
Proof that knowledge of Java alone is insufficient to be a Java
programmer - ditto for any language.
Nigel Wade wrote:
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.
[snip]
...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.
There is a security issue as well. The output to the file will remain
on the hard drive, albeit inaccessible from a normal directory link.
Sensitive data can be recovered by a determined attacker.
Certainly. It isn't meant to be a secure means of "hiding" data. Just a
convenient mechanism for implementing temporary files. Anything which is
essentially security-by-obscurity is not secure at all.
--
Nigel Wade