All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduard-Gabriel Munteanu <maxdamage@aladin.ro>
To: linux-kernel@vger.kernel.org
Subject: Forced unmounting for removable devices
Date: Thu, 30 Aug 2007 04:51:33 +0300	[thread overview]
Message-ID: <46D622A5.2000205@aladin.ro> (raw)

*This message was transferred with a trial version of CommuniGate(r) Pro*
This might have been discussed a few years ago, but things have changed. 
I'm talking about patches like this one (I'm not the author): 
http://developer.osdl.org/dev/fumount/#kernel1

The current situation requires a way to forcibly unmount removable 
media. Consider the following (real) scenario. Someone has a box with 
hald + dbus + ivman to support "supermounting" the CDROM drive. He has 
to install a 2 CD application using Wine for example, but the setup 
application prevents normal unmounting of the first one. Then he goes on 
and pushes the button to eject the CD, lazy-unmounting the media. The 
kernel goes mad and all attempts to load the second CD fail (the kernel 
hasn't got rid of the first fs).

If there was anything like a real forced unmounting, things would have 
worked well, as on MS Windows itself.

As far as I can see, there is no other sane way to solve such problems. 
So, what's keeping such patches from making their way into the 
mainstream kernel? All (but maybe I haven't searched enough) arguments 
against such a feature that I've seen by now just say "it's not needed", 
"it's not worth it" and so on, and many of them refer to network mounts.

P.S.: I'm not saying lazy unmounting should be replaced. They both make 
sense, depending on the scenario.

             reply	other threads:[~2007-08-30  1:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-30  1:51 Eduard-Gabriel Munteanu [this message]
2007-08-30  3:14 ` Forced unmounting for removable devices Salah Coronya
2007-08-31 15:35 ` Eduard-Gabriel Munteanu
2007-08-31 15:38   ` Al Viro
2007-08-31 15:38 ` Eduard-Gabriel Munteanu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46D622A5.2000205@aladin.ro \
    --to=maxdamage@aladin.ro \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.