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