(fwd) busybox mount -a fix.

[Paul Fox]

 > On Wednesday 21 June 2006 12:17 pm, Paul Fox wrote:
 > > the tricky part is that any EBUSY error will cause "mount -a" to
 > > always report success.  so if you have an fstab with one entry
 > > that's already mounted, and another that can't be mounted (e.g.,
 > > non-existent mountpoint), you'll get success.  (and since most
 > > fstabs usually contain at least one entry that's already mounted,
 > > what we usually see from "mount -a" is success.)
 > 
 > Is this still a problem after svn 15455?

you said you didn't know how to reproduce it, and asked for a
test case.  no, i don't believe it's still a problem after your
commit.

 > 
 > > except that i believe it's broken now.  now the mount exit code
 > > is indistinguishably either a count of failed mounts, or an
 > > errno.
 > 
 > For -a it's a count of failed mounts.  Without -a, it's an errno.  What's 
 > indistinguishable about this, you don't know whether you passed in -a?

i know of very few other programs (none?) whose exit codes vary
wildly given the arguments they're passed.  

 > 
 > You can't return an errno for -a because you could have different mounts fail 
 > for different reasons, and a count for the non-a case is always going to 
 > be "1".
 > 
 > In both cases, zero is success.

are there really other programs that return an errno as their
exit code?  i don't think i've ever encountered one, but maybe
i just didn't notice.

why are you inventing new behavior for the mount exit code?  granted,
it's odd behavior, and perhaps gratuitous on the part of the original
author, but i see no point in changing it arbitrarily.

 > 
 > So you want to support bits 32 and 64, but not bits 1, 2, 4, 8, or 16?  Why do 
 > bits 32 and 64 make sense in isolation?

i think it would be great to support all 7.  with my change we'd
support 1, 32, and 64.  i figure the other 4 would come in time.  we're
in feature freeze, remember?  ;-)

paul
=---------------------
 paul fox, pgf at brightstareng.com