On Sat, Jan 21, 2006 at 05:34:41PM +0100, Josip Rodin wrote:
> I'm sorry? How exactly am I clueless?
You forgot to RTFM.
> You think it's normal for mount to ignore the fact that
> mount.$fstype is ENOENT when mount() returned EINVAL?
Yes.
Read mount(8) and see:
Mount options for smbfs
Just like nfs, the smbfs implementation expects a binary argu-
ment (a struct smb_mount_data) to the mount system call. This
argument is constructed by smbmount(8) and the current version
of mount (2.12) does not know anything about smbfs.
That shows that mount is the wrong program to call.
But if you call it anyway, and you have mount.smbfs in place,
mount will invoke that, and things still work.
You will also find that if you search the manpage for the string smbfs.
The normal situation is that mount.$fstype returns ENOENT.
It is normal that there is no mount.$fstype - this is almost never
an error. If there is no special mount program for some type
then mount will do the generic mount call, and report on
error returns it gets from those.
It would be a mistake to build into mount knowledge about
all of the different filesystems - it is bad enough that it
knows about nfs.
So, the reporting from mount is generic, not filesystemtype-specific.
If there are problems for one particular type, then read the docs
and do dmesg | tail etc.
Andries
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
