GNOME Bugzilla – Bug 334806
Nautilus should inhibit gnome-power-manager when copying files
Last modified: 2009-10-07 20:50:36 UTC
I just dragged a 30GB folder from my external USB2 hard disk to my home directory and Nautilus started copying files as expected. After 5 minutes g-p-m put my system to sleep (because I've configured g-p-m that way). When my system resumed it did continue copying the files (yay! the kernel didn't suck). However, it would be nice if Nautilus or the VFS (feel free to reassign this feature request to the GNOME VFS product) would take a lock on the power manager when copying files so the system isn't put to sleep. Of course, g-p-m might not always honor this request in (for example, there may be more) the following situations; 1) battery is critically low; 2) the user pressed a sleep key or closed the lid; 3) the user selected "Sleep" from a menu Adding Richard Hughes (g-p-m maintainer) as I'm not sure g-p-m yet got this kind of functionality on it's D-BUS interface. If it doesn't we should probably open a bug against g-p-m and make this bug depend on it. Richard? Thanks, David
It hasn't, and I think we can (and should) introduce a simple dbus methods like gnome-screensaver does. Something like InhibitInactiveSleep and AllowInactiveSleep would match the gnome-screensaver way of doing things and would be easy to impliment. Adding Jon (gnome-screensaver author) as a CC.
Great idea, assigning to myself.
Yeah, this is one of the (possibly few) cases where the activity should not inhibit idleness/screensaver but power management directly. I looked into it for g-p-m a while back but I couldn't immediately figure out how to get the sender who uses a dbus glib method. This is one reason why in g-s we use the low level dbus API.
Jon, I had this problem with initial prototype versions of g-p-m, and havoc said that there was no easy solution in glib dbus (but then that was > 6 months ago, so things might have changed). I'll have a play with CVS dbus, and see if anything new has happened. David, if you can ask J5 for us, and see what he thinks please.
Christian: Awesome, thanks! Jon, Richard: Yea, I had the same problem when writing PolicyKit but after asking around on the dbus list I found a solution http://lists.freedesktop.org/archives/dbus/2006-March/004467.html Thanks, David
Cool, thanks David, thats exactly what I was looking for. David, can you create a bug for the g-p-m component "need to create InhibitInactiveSleep dbus method" and we can add that as a blocker for this nautilus functionality. Thanks.
Done, created bug 334809 that is blocking this one. Cheers.
More information on http://live.gnome.org/GnomePowerManager/Faq about how to inhibit the suspend. Thanks.
You'll want to use Inhibit() and UnInhibit(). See http://cvs.gnome.org/viewcvs/*checkout*/gnome-power-manager/docs/gnome-power-manager.html#pm-Compatibility This is due to XDG standardisation.
We will implement it as soon as D-Bus 1.0 is out.
I've been assured by J5 that dbus API shouldn't change much at all from now until 1.0 -- after the next release the version number is to be bumped to 0.90 to reflect this. Maybe just a --use-dbus flag (default off) might be okay?
According to http://dbus.freedesktop.org/ dbus version 1.0 was released a while ago. Any word on getting this fix implemented?
*** Bug 512867 has been marked as a duplicate of this bug. ***
Well, I've just tested again in Ubuntu 8.04.1, kernel 2.6.22-14-386, dbus 1.1.20, nautilus 2.22.3 and this still isn't fixed. This is really a pain since it's bugs like these which stop me from setting auto-suspend when i install ubuntu for very non-technical people, since they'll all be like wtf? Please fix!
Hugsie, am I correct in assuming that, after http://blogs.gnome.org/hughsie/2009/01/28/inhibits-and-the-new-world-order/ , This is the new API documentation to point developers to?: http://www.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Inhibit And... isn't this a perfect opportunity to kill a 3 years old bug? :) Nautilus is one of the last remaining pieces that doesn't seem to inhibit power saving properly. Cheers!
Yes, somebody just needs to patch nautilus to use the gnome-session inhibit methods. It should be pretty simple, but I've got close to zero time these days.
Quick question: can Nautilus call Inhibit() for each file job even if they're running concurrently (Uninhibit()ing at the end of each job, of course), or should it only call it once for the application as a whole? Otherwise, this should be a quick patch I think.
(In reply to comment #17) > Quick question: can Nautilus call Inhibit() for each file job even if they're > running concurrently (Uninhibit()ing at the end of each job, of course) Yes, you can have as many inhibits as you like for a single process, as they are all managed by a single uint32 cookie. Richard.
Created attachment 140346 [details] [review] patch Quick pass at this. Probably could use some reviewing & love before we merge it.
The patch looks good to me, except that you seem to remove nautilus_get_gmc_desktop_directory(), which should be done in a separate commit. Also, if you're removing the function, you should also remove the LEGACY_DESKTOP_DIRECTORY_NAME define.
Eep. That actually belongs to a different patch series, must have forgot to clean up the tree completely before branching. Committing with the patch noise removed.
Created attachment 140394 [details] bt Does this mean nautilus now depends on power manager running? I don't have g-p-m on my test system and nautilus now crashes when I try to delete files etc
Should just warn in the session log about it. The crash you're seeing was caused by a missed uninitialized GError in the failure case, and is fixed in HEAD.
*** Bug 554079 has been marked as a duplicate of this bug. ***