On Wed, Nov 15, 2000 at 08:13:23PM -0500, Greg A. Woods wrote:
> This is a bogus concern.  Any device which suffers this problem is
> broken by design and does not fit into the Unix model and should be
> fixed.  Open(2) and close(2) should never do "destructive" things of
> this sort.  If the device must not be rewound unexpectedly then it
> should require an explicit ioctl() to trigger the rewind and should not
> support a rewind-on-close.  Tapes in particular should always rewind on
> close so as to allow eject/removal/unmount (whether by mechanised or
> manual intervention) but they should not eject so that they cannot be
> used again without manual intervention.
	and you don't consider writing over what you just wrote to the
tape to be destructive?  What if you happen to have a tape that can
hold more than what you will write at once?  Why should whatever you
have writing to the tape (dump, dd, whatever..) have to be smart enough
to realize it's a tape, then issue a special ioctl so the next run will
write after it?  Instead of having the device know what to do in certain
cases now you'll have to teach every tool that you might want to use the
device.  
	Here's another idea: say you have a device that enforces exclusive access
(e.g. an audio device).  The device node has permissions to prevent joe
user from opening it.  Using a setuid program that does a supposedly safe
open/fstat/close joe user points it at the audio device, then suspends the
process. oh gee...  looks like I can't use my sound card anymore.

eric