Sam Steingold wrote:
> what I meant was that the _stream_ becomes a data sink.
> if the original file was new (in particular, it has no hard links),
then
> after deleting it, the inode would have no names, so there would be
> absolutely no way (known to me) to get to the data written to the
stream.
If there are other streams open to it, or the stream is bidirectional,
then you can get at the data. But I see what you mean, and I'm pretty
much niggling at this point.
What I was really geting at was that the file still uses blocks, so
writing to it isn't
the same thing as writing to /dev/null, as you can still fill up the
disk. So it's a sink with
(possibly) toxic side effects.
> ... but everything will be OK as soon as I kill the application,
right?
As soon as the fd is closed strictly, but yes (the filesystem is
reference counted, and an open file is a reference!)
(Incidentally, one case where this thing is done is where you want to
mmap a huge, sparse, file, for instance because you're snapshotting a
filesystem. If you create the file, do whatever mmappery is needed,
then unlink it, you run much less risk of this thing hanging around to
make your life miserable later, in particular when the backup program
decides it can't hack sparse files and tries to write some TB to
tape...)
>
--tim