Re: PROPOSAL for FHS revised : Mount points for CDs, floppies and a lien OS partitions.]
"Thomas Bushnell, BSG" wrote:
>
> Exactly why? FIFOs are also "quite different" but if an application
> wants a temporary fifo, it puts it in /tmp.
Yes, but applications do not need to ask users to insert a tape or disk
into a FIFO. The problem is that applications need to find a way by which
they can associate a file system node (whataver its name) with a physical
object visible to the user.
If there is only one such device, this can be done by opening it (say),
but this is no help in a multi-user multi-device situation: when suddenly
two CD drives open and the two users (still on talking terms, as the case
may be) come to an agreement which user should use which drive, how do they
tell the software whose CD is which drive ?
What happens if the users are hostile ? What happens if the handling of
physical media is done by an operator ? (Yes, I used to be in a mainframe
environment where this is common) What happens if the system is meant to
be neutral between users, and officially "can neither confirm nor deny"
to user X whether user Y has a CD-rom, and whether that is currently
mounted ?
> Dale Scheetz <dwarf@polaris.net> writes:
>
> > Your suggestion seems to be asking for a change in current practice, as
> > many distro's package managers already use /var/lib/<something>/ for their
> > temporary/volatile mount points. Would your idea of specifying
> > /tmp/<something> require that these packages move there mount points to
> > /tmp? Why would this be a good idea?
>
> I would object to *any* specification.
>
> My comments about /tmp are intended to point out that package managers
> already have a perfectly good solution, *already* supported. If they
> want to use /var/lib that's fine with me too.
But how does an installer find out whether "the" CD drive is already used
by another installer, mounting it on a different directory ? A "Well-known"
mountpoint would overcome this, although in current unix systems grepping
the contents of {/etc/mtab | /proc/mounts} or the output of mount, and
consolidating that with /etc/{v,}fstab and /etc/auto.* would probably get
a long way towards solving that. That of course supposes the files are
public and the mount command is not doctored to demand root.
In one of the mainframe environments I used (CDC NOS, NOS/BE) this was
solved thus (although I don't use all the the NOS syntax rules):
resourc cdrom=2
label rom vsn=fred=joe fn=bill seq=2
The resourc statement is required so that the system can estimate how many
allocateable devices the job needs to complete, thus avoiding deadlocks.
The label command displays to the operator the message "job xxx needs CD-Rom
fred", the operator puts it into the drive, and then types a command:
assign xxx cd-drive-4
Independent of this, the label command did scan the hardware, and would
notice that a newly closed cdrom drive contained the CD with Volume Serial
Number fred or joe, and assign it to the job. The dual naming is because
the actual CD-Rom was called joe when it was written, but then removed
from the machine room, and its place taken by a different disk. What the
operator would find now in the shelf reserved for the name joe is that other
disk, and the disk once called joe is now on the shelf and marked fred.
Once the disk has been identified, the label command would make file 2
(seq=2) with name bill - names are normal on CD-Roms, but the label command
would also work with tapes, which may or may not have names ("labels").
It would then make the file available under the name "rom" (in Unix terms,
in the current directory, but NOS or NOS/BE or MVS don't do directories).
Anything trying a sensible handling of removable media on Linux
would have to implement it similarly.
Thomas
* Why not use metric units and get it right first time, every time ?
*
* email: cmaae47 @ imperial.ac.uk
* voice: +4420-7594-6912 (day)
* fax: +4420-7594-6958
* snail: Thomas Sippel - Dau
* Linux Services Manager
* Imperial College of Science, Technology and Medicine
* The Center for Computing Services
* Exhibition Road
* Kensington SW7 2BX
* Great Britain
Reply to: