What was bug 1604?

[Denys Vlasenko]

On Sunday 31 October 2010 07:12, Rob Landley wrote:
> The current bugzilla database hasn't got a 1604, and I dunno where mantis is 
> archived.

I also don't have old mantis data.
However, I did find a mantis-generated email about it:

To: busybox-cvs at busybox.net
Subject: [BusyBox 0001604]: umount -D
Date: Fri, 23 Nov 2007 07:19:06 -0800
From: bugs at busybox.net
Message-ID: <64ddfd1c64a51be79d7292e780301214 at bugs.busybox.net>


The following issue has been SUBMITTED. 
====================================================================== 
http://busybox.net/bugs/view.php?id=1604 
====================================================================== 
Reported By:                alonbl
Assigned To:                BusyBox
====================================================================== 
Project:                    BusyBox
Issue ID:                   1604
Category:                   Standards Compliance
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             11-23-2007 07:19 PST
Last Modified:              11-23-2007 07:19 PST
====================================================================== 
Summary:                    umount -D
Description: 
Hello,
I am not sure how to classify this...
But util-linux does not have -D argument...
The default behavior is not to free loop device allocation, unless -d is
used.
Any reason why busybox behaves differently?
Thanks!
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-23-07 07:19  alonbl         New Issue                                    
11-23-07 07:19  alonbl         Status                   new => assigned     
11-23-07 07:19  alonbl         Assigned To               => BusyBox         
======================================================================



> Busybox umount was damaged by commit b2e578a1f2c3cf317 which made umount leak 
> /dev/loopX entries by default, but didn't stop umount from auto-allocating the 
> suckers.  So busybox mount/umount are now incoherent.  Wheee...

Yes.

> I have no idea what the rationale for this change was.

Users got bitten by the unnecessary discrepancy between bbox umount
and util-linux one. They would rather prefer that both utilities, where possible,
have the same options to specify the same thing. In this case,
util-linux umount has -d meaning "free loop device if there is one"
and we had -D "do not free loop device even if there is one".


> By the way, any time you say "non-standard", reference which standard.  The 
> mount and umount commands aren't in SUSv4.  BSD used vnconfig, slowaris used 
> lofi, macosx does something vaguely like FUSE...

Sure, there is no official, "paper" standard for mount utility.

Bash isn't standard either, yet you do see why other Linux shells
should emulate bash, instead of only implementing POSIX shell.
You yourself told me this many times, and I agree with you.

The situation with umount is analogous:

There indeed *is* a version of umount utility used by the majority
of Linux distros and "from scratch" installations: it's one from util-linux.
For practical purposes, it is "standard Linux umount".

If you don't like standard umount's options or behavior, there are ways
to fix it:

(a) join util-linux development team, and change it
    or
(b) develop an alternative which will eclipse util-linux in popularity.
    But in order to eclipse it, you need to attract user base.
    And you won't be very successful in it if you break command line
    compatibility without good reasons.

-- 
vda