Define GStatBuf as the type used by g_stat() and g_lstat(). Replaces
the non-public struct tag _g_stat_struct. Mostly relevant for Windows
where there are several variants of stat-style structs. On POSIX, is
just another name for struct stat.
Actually, also on many POSIX systems there are in fact several
variants of struct stat and corresponding stat() and lstat()
functions, but as g_stat and g_lstat are normally on POSIX just macros
that expand to stat and lstat, this should not cause a problem. It's
only when it's the actual g_stat() or g_lstat() implementation inside
GLib that gets called that one needs to be sure the passed struct is
the same as what GLib expects.)
We need to check priv->cancelled after taking the lock. Previously we
only checked it just before taking the lock, which left a small chance
for a race.
Don't keep the lists of source files for libglib, libgobject and
libgio in the VS project files in addition to the canonical location,
the corresponding Makefile.am files.
Instead, generate the corresponding .vcproj files at make dist time
using the C preprocessor, from template files called .vcprojin. We
still list explicitly in the .vcprojin files some of the
Windows-specific source files, and the sources files of gnulib and
pcre.
There might be a GSource attached to a GMainContext, about to be removed by a
pending cancellation. Deleting the handle too early will trigger a g_warning in
the "select()" call in GMainContext. Attached patch fixes this by deferring
destruction of WSAEVENT object until GSocket's finalize().
Patch from bug #612702.
Signed-off-by: Tor Lillqvist <tml@iki.fi>
It turns out that the way this worked did not work out for the current
main usecase (gedit) due to issues with how this is best integrated
with GtkTextView. So, in order to not have to support an unused non-ideal
API forever we remove this before its been in a stable release.
The basic feature seems to have some utility though, so we hope for it
to eventually return in a better form.
Some buildd environments have an unwritable $HOME, which makes the
test that looks for an unexisting file there fail. Use $TMP instead,
which should be more reliable.
https://bugzilla.gnome.org/show_bug.cgi?id=610860
root can access and write to a directory when it doesn't have
exec and write permissions respectively. So expect the tests that
check that to succeed rather than to fail when running as root.
https://bugzilla.gnome.org/show_bug.cgi?id=552912
This adds support for G_FILE_MONITOR_SEND_MOVED events when requested by
the user to the inotify backend. Last part to fix bug #547890.
Based heavily on a patch by Martyn Russel <martyn@lanedo.com>.
Add a G_FILE_MONITOR_SEND_MOVED flag indicating the API user
wants to receive the new G_FILE_MOINOTR_EVENT_MOVED event
instead of single CREATED/DELETED events.
First part of bug #547890.
The (linux specific) system call splice can be
used to transfer data between file descriptors
whitout copying them into user space.
See bug #604086 for additional details.
Fixes: Bug 604967 - 2.22.3 libasyncns build fails on HP-UX 11.11
* gio/libasyncns/asyncns.c: properly guard the includes of sys/select.h
and sys/time.h
If threads are available we always enable threads in gobject, which
means all gio/gobject code can enable the unconditional thread calls.
This is a minor optimization since we avoid a bunch of unnecessary
is-threads-enabled checks.
https://bugzilla.gnome.org/show_bug.cgi?id=606775
Adds an optional query method to giomodules which should return all
possible extension points the module may implement.
Then we add a new call g_io_modules_scan_all_in_directory() similar to
g_io_modules_load_all_in_directory() that doesn't return all loaded
modules, thus allowing lazy loading.
In g_io_modules_scan_all_in_directory we look for an optional
giomodule.cache file and use the information in that to avoid
loading modules until they are needed for an extension point.
In the deserialise function, GUnixFDMessage was comparing 'level' to
both SOL_SOCKET and SCM_RIGHTS. It is correct to compare 'type' to
SCM_RIGHTS. The code passed tests only because:
1) it's a "should always be OK" double-check
2) SOL_SOCKET and SCM_RIGHTS, by chance, both have the value '1' on
Linux systems.
Not only is the default implementation broken (it causes infinite recursion
as seen in bug #603982), but its also worthless. If we just fall back on the
default stream operations we automatically get async version based on
the sync filter stream operations, which is what we want.
Note: Since we export types with Iface in the name rather than
Interface we have to use some typedefs to make this work. New
interfaces should probably use Interface as the public name.
The "default location" of the given mount is a path that reflects
the main entry point for the user (e.g. the home directory, or the
root of the volume).
https://bugzilla.gnome.org/show_bug.cgi?id=561998
• "asynchronous" was misspelled as "asyncronous" in various places;
• punctuation was missing;
• g_async_initable_new_async() had a stray "and";
• references to g_async_initable_new_finish() were missing a "the".
https://bugzilla.gnome.org/show_bug.cgi?id=602417
This is an interface for stateful conversions of data. Its a generic
interface suitable for things like IConv, compression, decompression,
and regexp replacement.
Introduced a more precise error message for EPERM when symlinking to
a local filesystem.
EPERM on symlink means symlinking is not supported by the underlying
fs so it is not the general meaning of EPERM which roughly translates
to 'Operation not permitted'.
Since returning exactly one match has special significance, don't
give up matching before we've found at least 2 types. Also, make
sure that we don't return the same mime type more than once.
Bug 541236.
GWin32DirectoryMonitor was quite broken, but nobody had apparently
noticed, or at least not filed any bug. Only now with a bleeding edge
GTK+ file chooser does the code get exercised in common programs like
gtk-demo or GIMP, apparently. Bug #598899.
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
