RFC: Kernel changes that may affect desktops
Ben Boeckel
MathStuf at gmail.com
Wed Jul 1 01:01:45 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matthew Garrett wrote:
> On Wed, Jul 01, 2009 at 12:31:20AM +0200, Kevin Kofler wrote:
>
>> IMHO DeviceKit should just unmount it itself and notify the
desktop that it
>> has unmounted the device so the desktop can report it (or
ignore it if it
>> doesn't know about the event). I don't see why we need to
add code to every
>> desktop to listen for a "please unmount me" event and send
an unmount
>> request back when this could just be handled within
DeviceKit. Or even
>> within the kernel for that matter, do we really need a
roundtrip through
>> userspace for this? When and why would we ever want to do
anything *other*
>> than unmounting the device when this event triggers?
>
> Because you might want to warn the user that they have
unsaved work that
> will be lost if they continue?
Isn't there "Save As..." for saving it? If not, I smell a bug
report. When I'm working over sshfs and the network goes down,
my editor still works with the file, the actual save is what
fails.
>> An additional problem is: what if the unmount fails due to
open files? Your
>> suggestion to just kill the applications sounds really
broken to me. A
>> forced unmount at kernel level and failing any attempts to
further access
>> that file just like what happens when an NFS mount goes
offline sounds like
>> a better solution to me.
>
> There are alternatives, like revoking the filehandles or
prompting the
> user to close the application themselves. This is the same
problem faced
> when unmounting any device.
Umm, Windows locks files when they're opened. AFAIK, Linux
doesn't enforce this.
A similar problem is this:
mkdir foo
touch foo/bar
kwrite foo/bar &
rm -rf foo
Should kwrite be killed because rm killed the directory?
- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpKtXkACgkQiPi+MRHG3qTVrgCfXM3ItQpUBYzK1JT91RoJ4rjy
fNEAoKEkgrII4JNkaundDYMv76fTAD69
=qUfz
-----END PGP SIGNATURE-----
More information about the fedora-devel-list
mailing list