On Fri, 7 Jun 2002, Robert Elz wrote:

#   | I agree with you, but I'm not so sure I agree with Thor.
#
# I do.
#
#   | While
#   | obviously a file with no directory references is probably intended only
#   | for temporary data, I'm not sure fsck should make such an assumption,
#
# Of course it can, because that's what the application is telling it.
# If an application unlinks its temp file, the application (the app's
# author) is indicating "this temp file is trash, there's no use at all
# recovering it if the application crashes or the system does").

# If the application is unlinking temporary files which could be usefully
# recovered, then the application is broken, and that's where the fix
# should be applied, making fsck do dumb things to compensate is just
# plain wrong.
#
# kre
#
# ps: the other argument made for this "I just removed a valuable file that I
# know is open in this application, but which has no way to save the file, so
# I'm going to push RESET and then fsck will make the file come back" is just
# so ludicrous as to not be worthy of any comment at all.

I agree that the app is broken; however, having a way to recover is not
such a bad thing.  I think that one should be offered the option to
reconnect in interactive mode.

I don't think that such a thing should be done in preen mode unless
explicitly requested, though, and I don't think that a system should be
configured to explicitly request it by default, since if you don't know
what you're doing, you will end up with a very full filesystem after a
reboot someday.

And it really doesn't seem to me that fsck is a bad place to do this;
after all, fsck is where the recovery is done after a crash.

				--*greywolf;
--
NetBSD:  Don't login as root, use the su command.