On Tue, Jun 27, 2000 at 11:10:31AM -0700, Daniel Quinlan wrote:
> Addressing the technical issue at hand, /mnt has been specified as a
> single mount point for temporary use since the original FSSTND 1.0
> released on February 14, 1994 (and it was used that way on every
> distribution predating FSSTND).
Is there an actual problem with Red Hat having subdirectories like
/mnt/floppy? Or Debian having /floppy? At the absolute worst, the admin
can just rm them and adjust it to suit.
We've already got:
] This directory is provided so that the system administrator may
] temporarily mount filesystems as needed. The content of this directory
] is a local issue and should not affect the manner in which any program
] is run.
which seems to me to be both consistent with all the various existing
practice (/mnt is used for temporary filesystems as needed, even if only
by proxy via /mnt/floppy; and it's a *local issue* which doesn't require
more standardisation).
The only language that might be worth changing is:
] Software should never create or require special files or subdirectories
] in the root directory.
which seems to forbid /floppy (since it's created by the OS distributor's
software).
> Multiple directories under /mnt also conflicts with the
> standard system administration practice of mounting on /mnt --
But note that directories under /mnt is now a standard system
administration practice too. And since the contents of /mnt *are* a
local issue, there's no reason for the FHS, LSB, or third party vendors
to worry about it at all.
> However, it does seem that we could benefit from having a subdirectory
> off of / or /var for temporary mount points, even if the structure
> therein is loosely defined.
Why not leave that to system administrators and OS distributors? If all
we're going to say about something is "this may or may not be here, and
its contents may or may not be important" it's barely even worth putting
it in the spec. Even if someone rmdir's /mnt and only mounts filesystems
under /var/local/screw-the-fhs, none of their software should have any
reason whatsoever to break.
Cheers,
aj, against overspecification
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgp2b2sTZK_Pk.pgp
Description: PGP signature