Add API for starting/stopping drives. This new API will enable
GVolumeMonitor and GVfs implementations to add support for the
following features
1. Powering down external hard disk enclosures / drives
2. Starting/stopping multi-disk devices (such as RAID/btrfs/ZFS)
3. Connecting/disconnecting iSCSI devices
4. Reacting to the user pressing e.g. the "remove drive" button on
a IBM/Lenovo Ultrabay: http://www.thinkwiki.org/wiki/Ultrabay
See the bug for the corresponding GVfs and Nautilus changes.
The icon names are folder-documents, folder-download, folder-music,
folder-pictures, folder-publicshare, folder-templates, folder-videos.
See bug 541276.
Change the logic in g_socket_listener_add_inet_port() as per the
reasoning in the bug report.
- If the OS supports neither IPv6 or IPv4, fail.
- If the OS supports only IPv6, do that.
- If the OS supports only IPv4, do that.
- If the OS supports IPv6 and IPv6 "speaks" IPv4 then bind it
and be done.
- If the OS supports IPv6 and IPv6 doesn't "speak" IPv4 then
create an additional socket for IPv4.
- If binding any socket fails then fail the entire call.
Also, remove the ability to call this function with port == 0. This
is a useless thing to do anyway since you have no way to know what
port number was actually allocated. We should have a separate
function to deal with this.
... as g_cancellable_cancel()
Rework a g_critical() that would (rarely) trigger when _reset() was
called in a thread different from _cancel() by making _reset() wait for
the cancel function to be finished the same way
g_cancellable_disconnect() uses.
The default implementation of g_file_copy() checked the size of the file
to copy to give useful progress updates unconditionally. This can cause
long delays on 1-connection FTP servers while it tries to open a second
connection before it returns EBUSY. This patch makes this query only
happen when we actually send progress updates.
In particular, targets with weight 0 should be very UNlikely to be
selected, not very likely, as they were before. However, even ignoring
that bug in the logic, there was an additional bug (swapping list
items would cause the 0-weight items to get re-ordered incorrectly
anyway), and the code contained several fencepost errors.
This patch also adds gio/tests/srvtarget.c, which confirms that for a
sample list of targets, we now generate all possible correct random
sortings and no incorrect sortings, and the correct sortings occur in
roughly the expected proportions (though if the current code is
still wrong, those proportions may be wrong as well).
http://bugzilla.gnome.org/show_bug.cgi?id=583398
