Date:        Mon, 10 Jun 2002 12:14:06 -0400 (EDT)
    From:        der Mouse <mouse@Rodents.Montreal.QC.CA>
    Message-ID:  <200206101614.MAA13292@Sparkle.Rodents.Montreal.QC.CA>

  | fsck's raison d'etre is to bring the filesystem into an internally
  | self-consistent state, a state that it could have been in upon a clean
  | shutdown.  It is impossible to do this in the circumstances described
  | without either losing or recovering the data in question.

The data was lost when the application unlinked it.  Either the kernel
(when the app exits/dies) or fsck (if the system crashed) are just
completing the job.

  | Not all added code is bloat.

No, of course not, but ...

  | and the price is so low that I don't
  | consider it bloat even though I will probably never use the option 

Options that aren't used are bloat - no matter how little the code
changes are.

Also remember in this, the part that I suspect hasn't get been done.
That's the doc - it is going to bloat by much more than the code, by
the time it indicates just what the option does, and when/why someone
might need to use the thing.

  | You really think this sort of lossage will happen only once in my (or
  | greywolf's) career?

No, but I suspect that you'd be so sick of the option re-attaching files
that weren't supposed to be, that you would not have it enabled, then
the system crashes, reboots, and fsck cleans up the files, before you
get a chance to prevent it - then you curse, enable the option for the
next time .. .but once again get tired of it before it ever turns out to
be useful again.

In any case, my rough judgment of what has happened here is that the
option isn't going to get added anyway - there are better ways to solve
the problem when you actually need to solve it.

kre