Silent failure of busybox mount for unknown fs type

[Vladimir Dronnikov]

>> >
>> > I added bb_perror_msg("can't execute '%s'", argv[0])
>> > in spawn() in git...
>>
>> Hmm. spawn() was meant to be silent.
>
> Set logmode = 0 and it will be.
>

What is impact in other applets then? I never knew of "logmode" at
all. Where is it? What is it? Anyone knows of it?

>> It is mount.c that should bark
>> unless quiet option is given, IMHO.
>
> It is hard to reliably detect exec failure after fork.
> Parent can only see they child exited with some exitcode or signal,
> how it can know that child exited because exec in the child failed?
>

Right. But then the routinr deserves to be named WARN_UNLESS_spawn(),
doesn't it? And, personally, spent time to make ntfs-3g mount helper
silent (patch can be given) if it is a helper to mount NTFS. Otherwise
it constantly barks when I try ti auto-mount non-NTFS devices which
happen to have filesystem named farther than ntfs (squashfs, e.g.) --
that is because the kenrel tries to auto=probe filesystems by the
order
thay go in /{etc,proc}/filesystems (really, kernel-side Kbuild(s)). Do
we mean it?

>> And may be to print this error
>> only if fstype is explicitly given?
>
> I think it's not bad to give more diagnostic.

Again, given the principal of "least intervention" (or how they say it
in english), it is way serious change in mount behaviuor.
At least, such a spawn()'s behaviour should be guarded against
FEATURE_MOUNT_HELPERS, right? Or the net result is that
we change the behaviour of _all_ applets depending on spawn(), just to
make mount.c' users happy?!


> --
Vladimir