[ On Wednesday, November 15, 2000 at 17:34:22 (-0800), Greywolf wrote: ]
> Subject: Re: Addition to force open to open only regular files 
>
> Agreed, sort of, but I suggest you go back and check your own historic
> device trees.  I seem to recall
> 
> 	/dev/rmt/0n	no-rewind
> 	/dev/rmt/0hn	no-rewind high-density
> 
> etc.

I'm not so worried about a tape rewinding.  Sure it's a bit of a pain in
the butt, especially if it happens at an extremely inopportune time.

However it's quite likely that anything which could be adversely
affected by such an operation will have the device open already, in
which case either the second open will be failed (EBUSY) or the errant
close will not do anything because it's not the last close (or if it is
the last close then it'll only delay the rewind a bit).

So, yeah, scripts and programs that mess around with the tape could be
fooled because they don't keep the device open all the time.  The risks
of such a vulnerability are, I think, relatively low.  Maybe a bad guy
could cause the logs just archived to tape to be overwritten by the next
filesystems, but like I say, the risks are relatively low....

> GACK!  What are you SAYING?  Tapes should ALWAYS REWIND ON CLOSE?

Well, yes, unless of course you use the no-rewind device....  That
should be obvious!  :-)
 
Other than 8-track (audio) and maybe some older QIC tapes, I can't think
of any tape-style devices that don't need to be rewound, at least before
next reuse if not before being removed from the drive.

Of course the no-rewind minor device is really just a hack to allow
programs to manage multiple files on one tape.  One could just as easily
have used the "mount" paradigm to do the same sort of thing, and of
course now with virtual filesystem concepts readily available this makes
even more sense -- "mount /dev/st0 /tape01" would maybe create a virtual
directory showing at minimum a device node that would be used just as
the raw tape would be used (perhaps several for different densities or
compression if supported), and might also contain a status file that can
be read at any time, and maybe even a control file as you suggest below.
Unmounting the tape would only be possible once all the "files" had been
closed, and would perform any rewind or other physical operations
necessary to ready the tape media for removal.  A "-noeject" option on
umount (or mount) could be used to prevent mechanical media ejection on
those devices that support such a feature.  You could even use a floppy
or other removal random-access secondary storage device as a linear tape
in this manner.  This would also make it easier to properly delegate
publicly accessible devices to individual users for the period their
media was in the device (though you still really need some kind of
pre-access locking prior to device access to ensure that the device will
be yours after you put your media in it).

> I *do* think that handling all this via the minor number is an
> unmistakable flaw with which, regrettably, we are somewhat stuck,
> since programs like tar, dd, dump, restore and the like tend to blindly
> open the device and go about their business.

I agree.  It should never have been a feature of the minor number.

I suppose it does make writing portable multi-tape backup programs a
tiny bit easier, but that hardly seems like an excuse.

Such design flaws can always be fixed -- it's just a matter of accepting
the work-load and the complaints from programmers who'll inevitably say
that they don't like dealing with the differences.  Of course if the
idea is sound and shows merit over the old way it'll stand a chance of
propogating to other systems and thus eliminate the differences.

> Do we need a /dev/rmt controlling device to say something like
> "set norewind,high-density on 0"?  (that might create a race condition
> if someone's sitting on /dev/rmt waiting for you to open the tape drive).

I prefer ioctl() for this kind of thing, even though it's a gross and
half-baked API in some ways, it does have some advantages as you say.

One could do really ugly things like require that the control minor only
be opened by a process that's already got the read/write minor open (or
vice versa), but I'd rather deal with ioctl() magic than this kind of
weirdness.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>