mount is obtuse?

This is not a critics, I'm just curious to understand the rationale behind the fact that mount does not recognizes other filesystem and provides very poor error messages (according to me) when you try to mount something not UFS.
On the other hand, OpenBSD mount "routes" the request to the rigtht command, like to mount_msdos.

I like the fact that a single command does a single thing, not involving other commands transparently, I'm just curious about this behavior.[/cmd]
 
You can specify type of file system. From mount(8):
Code:
     -t [no]type[,type ...]
             The argument following the -t is used to indicate the file system
             type.  The type ufs is the default.  The -t option can be used to
             indicate that the actions should only be taken on file systems of
             the specified type.  More than one type may be specified in a
             comma separated list.  The list of file system types can be
             prefixed with no to specify the file system types for which
             action should not be taken.  For example, the mount command:

                   mount -a -t nonfs,nullfs

             mounts all file systems except those of type NFS and NULLFS.

             The default behavior of mount is to pass the -t option directly
             to the nmount(2) system call in the fstype option.

             However, for the following file system types: cd9660, mfs,
             msdosfs, nfs, nullfs, smbfs, udf, and unionfs mount will not call
             nmount(2) directly and will instead attempt to execute a program
             in /sbin/mount_type where type is replaced by the file system
             type name.  For example, nfs file systems are mounted by the
             program /sbin/mount_nfs.

             Most file systems will be dynamically loaded by the kernel if not
             already present, and if the kernel module is available.
 
On the other hand, OpenBSD mount "routes" the request to the rigtht command, like to mount_msdos.
However, for the following file system types: cd9660, mfs, msdosfs, nfs, nullfs, smbfs, udf, and unionfs mount will not call nmount(2) directly and will instead attempt to execute a program in /sbin/mount_type where type is replaced by the file system type name. For example, nfs file systems are mounted by the program /sbin/mount_nfs.
This sound like FreeBSD mount(8) do the same too?
 
Old school here, I prefer to know what something is and explicitly stating things. That's where dmesg and fstyp come into play. It helps prevent "mounting the wrong type and breaking things". Some of the special file types like cd9960: I've done the create a memory disk mount point the mount ISO image on top to actually recover systems, so I'm not sure a basic "mount" should be able to do this.
 
Old school here, I prefer to know what something is and explicitly stating things. That's where dmesg and fstyp come into play. It helps prevent "mounting the wrong type and breaking things". Some of the special file types like cd9960: I've done the create a memory disk mount point the mount ISO image on top to actually recover systems, so I'm not sure a basic "mount" should be able to do this.
100% agree! Be aware of what hardware you use and you will control your system and not vice versa.

You know, I happened to ask some MS Windows users what type of filesystem they have on their USB stick they gave me and all of them were like:
- eeeh... I Dunno...
And I was like: - What? How do you use it then?
- Well, I just plug it in and then just plug it off when I'm done...

And shall I tell you that all of them have absolutely _no_idea_ what word 'mount' means? Oh, yeah, that's because in MS Windows you don't even have to worry about that: it's 'auto-mounted' when you stick it by default. And every single one USB stick I took from them was not unmounted properly and needed to be fixed at some point, because people don't known that it must be unmounted before you plug it off.

I mean, alarm! People don't known what hardware they use. They can't tell HDD from RAM.
 
Back
Top