The source can be destroyed by the time we complete the result, and
then the g_source_get_context(current_source) call will cause
a critical error. We check for the source being destroyed and avoid
the check in that case.
This means we miss the right-thread check in this case, but thats
merely a helper, so this is not critical.
Metadata are really part of the pathname, not the target file
(as they are stored by pathname, and for many metadata like icon position
etc make not sense using the target data). So, even if nofollow
is not specified we should not follow links for metadata.
Ideally this should be implemented in the metadata extension in gvfs,
but the extension API does not allow this, so we do it in gio.
See https://bugzilla.gnome.org/show_bug.cgi?id=593809
g_network_address_address_enumerator_next_finish takes the first item of the
address list and moves the pointer to the next one, so we shouldn't do the same
in g_network_address_address_enumerator_next_async function
Fixes bug #593941
g_socket_send_message() and g_socket_send_to() fail with ENOBUFS or
EFAULT due to the fact that if no "address" argument is specified to
g_socket_send_message, when g_socket_send_message() calls sendmsg(2),
the 2nd parameter to sendmsg ("const struct msghdr *msg") contains
uninitialized values. The fix is simple - initialize msg.msg_name to
NULL and msg.msg_msg_namelen to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=594759
This warning hits code that uses GSimpleAsyncResult outside of a
mainloop as a helper object. For instance EggDBus does this.
Since the bugs this warning would fix are pretty easy to spot
and since EggDBus is deployed already we just remove the
"called from outside main loop" warning.
However, we need to keep the "called from wrong context" warning
as that is very helpful when debugging misuse of the new multiple
main context code.
Previous code used g_mkstemp(). But when using
G_FILE_CREATE_REPLACE_DESTINATION, no attempt was made to ensure proper
mode and flags of the created temporary file. The visible issue was that
the file was always created with mode 0600 as opposed to using 0666.
(The invisible issue was that O_RDWR was used instead of O_WRONLY.)
When doing a g_file_copy() with nofollow-symlinks (to copy a link for
example), the later copying of the file attributes copies the source
links 777 attributes to the target's attributes. As chmod affects the
symlink target, this would cause such copies to always set the target to
777 mode.
This patch makes setting the mode with nofollow-symlinks fail with
NOT_SUPPORTED.
The aforementioned g_file_copy() will still succeed, because it ignores
errors of the attribute copy.
Even though we ignore SIGPIPE, gdb will still stop when the process
receives one, which sometimes confuses people into thinking the app
has crashed (eg, bug 578984, bug 590420), and is annoying anyway. So
use MSG_NOSIGNAL if it's there.
http://bugzilla.gnome.org/show_bug.cgi?id=591378
This patch only adds the function. The function is a NOP.
See the API documentation for a rationale.
Part of: Bug 591388 - number of GCancellables available is too limited
For details, see bug 587482. The new api:
- Provide new _with_operation() variants of all unmount and eject methods
- Add GMountOperation::show-processes signal
- this can be used to show processes blocking an unmount operation
- Deprecate all unmount and eject methods
- Add g_drive_can_start_degraded() method
- this is to avoid auto-starting degraded drives
- Make g_drive_stop() resp. g_file_stop_mountable() take a GMountOperation
- these ops were recently added and not yet public API so it's fine
to change how they work
- Provide a way to poll mountable files, e.g. g_file_poll_mountable()
- Add some missing file attributes for mountable files
- G_FILE_ATTRIBUTE_MOUNTABLE_UNIX_DEVICE_FILE
- needed for the GDU Nautilus extensions to format a volume
- G_FILE_ATTRIBUTE_MOUNTABLE_CAN_START_DEGRADED:
- mimics g_drive_can_start_degraded()
- G_FILE_ATTRIBUTE_MOUNTABLE_CAN_POLL:
- mimics g_drive_can_poll_for_media()
- G_FILE_ATTRIBUTE_MOUNTABLE_IS_MEDIA_CHECK_AUTOMATIC
- mimics g_drive_is_media_check_automatic()
g_simple_async_result_complete() now checks that it's being run from
the correct main loop, so tests/gio/simple-async-result was failing,
because it called it from outside any main loop. (And gio's pltcheck
was failing because I hadn't added g_main_current_source() to it.)
GFile allows for the possibility that external implementations may not
support thread-default contexts yet, via
g_file_supports_thread_contexts(). GVolumeMonitor is not yet
thread-default-context aware.
Add a test program to verify that basic gio async ops work correctly
in non-default contexts.
http://bugzilla.gnome.org/show_bug.cgi?id=579984
Currently, to implement cancellability correctly, all synchronous
calls to GSocket must be preceded by a g_socket_condition_wait() call,
(even though GSocket does this internally as well) and all
asynchronous calls must do occasional manual
g_cancellable_is_cancelled() checks. Since it's trivial to do these
checks inside GSocket instead, and we don't particularly want to
encourage people to use the APIs non-cancellably, move the
cancellation support into GSocket and simplify the existing callers.
http://bugzilla.gnome.org/show_bug.cgi?id=586797
This patch and the previous ones fixes the performance issues noted in
Bug 587089 – lookup_attribute() takes too much CPU
It increases performance for querying attributes by ~15% in my tests.
g_filename_complete_get_completions() return value is meant to be a
g_strfreev-compatible array i.e. NULL-terminated. However, pointer arrays
aren't automagically NULL-terminated. This fixes bug 586868
I'm not sure why we used the elaborate formula to convert the io-priority
to the priority of the mainloop idle when emulating async i/o with idles.
However, it causes the default io priority to be less than the normal
idle prio, so the i/o won't be scheduled if there is an idle outstanding.
There is really no great mapping to use here, doing blocking i/o in an
idle of any prio is generally bad and apps doing a lot of async i/o should
initialize threads. However, if we use the io-priority directly we at least
avoid the starvation problem above and make things easier to understand.
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
Do proper referencing and unreferencing of
GWinHttpFileInputStream::file and
GWinHttpFileInputStream::file::vfs. Implement
GWinHttpFileInputStream::close_fn.
The docs mentions a separate seekable API for the various file streams
which don't actually exists. Change this to refer to the generic
GSeekable calls.
It was possible for a signal handler to remove the last reference and
dispose the monitor. If there were remaining pending_file_changes they
tried to dereference the disposed monitor.
This patch simply calls g_object_{ref,unref} around the loop that signals
the changes.
