Re: rm-ing files with open file descriptors

[Ken Brownfield]

This is actually a long-standing UNIXism that is pretty heavily relied-
upon -- for example, opening a temporary file then unlinking it before
use "guarantees" that the file will not stick around in case the app
crashes before it can properly close and unlink.

One nasty side-effect is space allocation -- after unlinking a file and
writing to it, you can fill the disk without the file showing up in 'ls'
or 'du', etc.  Hard to debug.  Stronghold on Solaris used to do this
with log files -- HUP did not discard the old FDs.

-- 
Ken.
[e-mail]

On Fri, Jan 18, 2002 at 04:11:26PM -0500, Doug Alcorn wrote:
| 
| I had a weird situation with my application where the user deleted all
| the database files while the app was still reading and writing to the
| opened file descriptor.  What was weird to me was that the app didn't
| complain.  It just went merrily about it's business as if nothing were
| wrong.  Of course, after the app shut down all it's data was lost.
| 
| Since I didn't expect this behavior I wrote a simple little program to
| test it[1].  Sure enough, you can rm a file that has opened file
| descriptors and no errors are generated.  Interestingly, sun solaris
| does the same thing.  Since this is the case, I thought this might be
| a feature instead of a bug (ms-win doesn't allow the rm).  So, my
| question is where is this behavior defined?  Is it a kernel issue?
| Does POSIX define this behavior?  Is it a libc issue?  
| 
| I tried to google this, but couldn't think of the right terms to
| describe it.  As I'm not on lkm, I would appreciate a CC: to
| <[e-mail]>.
| -- 
|  (__) Doug Alcorn (mailto:[e-mail] http://www.lathi.net)
|  oo / PGP 02B3 1E26 BCF2 9AAF 93F1  61D7 450C B264 3E63 D543
|  |_/  If you're a capitalist and you have the best goods and they're
|       free, you don't have to proselytize, you just have to wait. 
| 
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to [e-mail]
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at  http://www.tux.org/lkml/