After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 334806 - Nautilus should inhibit gnome-power-manager when copying files
Nautilus should inhibit gnome-power-manager when copying files
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.14.x
Other All
: Normal enhancement
: ---
Assigned To: Christian Neumair
Nautilus Maintainers
: 512867 554079 (view as bug list)
Depends on: 334809
Blocks:
 
 
Reported: 2006-03-16 19:58 UTC by David Zeuthen (not reading bugmail)
Modified: 2009-10-07 20:50 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
patch (8.83 KB, patch)
2009-08-10 15:52 UTC, A. Walton
reviewed Details | Review
bt (6.45 KB, text/plain)
2009-08-10 23:27 UTC, Michael Monreal
  Details

Description David Zeuthen (not reading bugmail) 2006-03-16 19:58:03 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
Comment 1 Richard Hughes 2006-03-16 20:12:54 UTC
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.
Comment 2 Christian Neumair 2006-03-16 20:23:05 UTC
Great idea, assigning to myself.
Comment 3 William Jon McCann 2006-03-16 20:28:20 UTC
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.
Comment 4 Richard Hughes 2006-03-16 20:39:44 UTC
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.
Comment 5 David Zeuthen (not reading bugmail) 2006-03-16 20:47:16 UTC
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
Comment 6 Richard Hughes 2006-03-16 20:53:03 UTC
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.
Comment 7 David Zeuthen (not reading bugmail) 2006-03-16 21:05:34 UTC
Done, created bug 334809 that is blocking this one. Cheers.
Comment 8 Richard Hughes 2006-03-23 16:55:22 UTC
More information on http://live.gnome.org/GnomePowerManager/Faq about how to inhibit the suspend. Thanks.
Comment 9 Richard Hughes 2006-06-10 11:14:59 UTC
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.
Comment 10 Christian Neumair 2006-06-11 10:18:14 UTC
We will implement it as soon as D-Bus 1.0 is out.
Comment 11 Richard Hughes 2006-06-11 10:31:09 UTC
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?
Comment 12 Alex Deriziotis 2007-12-03 15:27:01 UTC
According to http://dbus.freedesktop.org/ dbus version 1.0 was released a while ago.

Any word on getting this fix implemented?
Comment 13 Cosimo Cecchi 2008-01-29 23:45:00 UTC
*** Bug 512867 has been marked as a duplicate of this bug. ***
Comment 14 Alex Deriziotis 2008-07-28 11:06:03 UTC
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!
Comment 15 Jean-François Fortin Tam 2009-08-10 01:07:54 UTC
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!
Comment 16 Richard Hughes 2009-08-10 09:44:27 UTC
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.
Comment 17 A. Walton 2009-08-10 12:26:34 UTC
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.
Comment 18 Richard Hughes 2009-08-10 12:36:52 UTC
(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.


Comment 19 A. Walton 2009-08-10 15:52:47 UTC
Created attachment 140346 [details] [review]
patch

Quick pass at this. Probably could use some reviewing & love before we merge it.
Comment 20 Cosimo Cecchi 2009-08-10 16:30:59 UTC
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.
Comment 21 A. Walton 2009-08-10 17:07:34 UTC
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.
Comment 22 Michael Monreal 2009-08-10 23:27:10 UTC
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
Comment 23 A. Walton 2009-08-10 23:59:05 UTC
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.
Comment 24 A. Walton 2009-10-07 20:50:36 UTC
*** Bug 554079 has been marked as a duplicate of this bug. ***