We have turned up enough cases of this being done (including GTK API
allowing apps to do this to GtkSettings well after it has been
instantiated) that it is clear that we cannot really break this feature
while claiming to be backwards compatible.
For that reason, it becomes a warning rather than a critical (ie: it is
still well-defined behaviour, but you are discouraged from doing it).
The intention is to keep this feature for at least the next while.
A given GObjectClass will be able to avoid using GParamSpec pool for as
long as you don't install properties after init. If you do that, you
will get a warning and we will devolve to using GParamSpecPool.
https://bugzilla.gnome.org/show_bug.cgi?id=698614
When parsing an address, we need to re-set "len" between IPv4 and
IPv6, since WSAStringToAddress() might set it to sizeof(struct sin_addr)
when trying to parse the string as IPv4, even if it fails. Also, we
need to make sure to not pass strings to WSAStringToAddress() that it
will accept but that we don't want it to.
When stringifying an address, we need to clear the sockaddr before
filling it in, so we don't accidentally end up with an unwanted
scope_id or the like.
https://bugzilla.gnome.org/show_bug.cgi?id=701401
Previously, g_file_copy() would (on Unix) create files with the
default mode of 644. For applications which might at user request
copy arbitrary private files such as ~/.ssh or /etc/shadow, a
world-readable copy would be temporarily exposed.
This patch is suboptimal in that it *only* fixes g_file_copy()
for the case where both source and destination are instances of
GLocalFile on Unix.
The reason for this is that the public GFile APIs for creating files
allow very limited control over the access permissions for the created
file; one can either say a file is "private" or not. Fixing
this by adding e.g. g_file_create_with_attributes() would make sense,
except this would entail 8 new API calls for all the variants of
_create(), _create_async(), _replace(), _replace_async(),
_create_readwrite(), _create_readwrite_async(), _replace_readwrite(),
_replace_readwrite_async(). That can be done as a separate patch
later.
https://bugzilla.gnome.org/show_bug.cgi?id=699959
Previously, we called g_file_query_info() *again* on the source at the
very end of the copy. This has the lame semantics that if the source
happened to be deleted, we would fail to apply attributes to the
destination. This could even be a security flaw.
This commit changes things so that we query info from the source
*stream* after opening - i.e. on Unix we use the proper fstat() and
friends. That way we operate more atomically.
https://bugzilla.gnome.org/show_bug.cgi?id=699959
The freedesktop application specification is largely overlapping the
GLib application D-Bus interface but implementing it will allow for
applications to be launched directly from desktop files, which we want.
We keep the old Gtk interface for compatibility reasons and because it
has some functionality not in the freedesktop spec (Busy state,
CommandLine, etc.).
https://bugzilla.gnome.org/show_bug.cgi?id=699259
Since services are based on D-Bus activation and desktop files are
supposed to be named like the busname for DBusActivatable applications
and since gnome-shell wants wmclass equal to the desktop file name, we
therefore want wmclass equal to the application ID in this case.
wmclass is determined from the prgname, which is otherwise pretty
pointless to set to some random thing in $(libexec) for a D-Bus service,
so set that to the appid.
This means that for D-Bus services, the following things are now all the
same:
- application ID
- prgname
- wmclass property set on all windows
- desktop file name
- well-known bus name
There are not many applications running as D-Bus services at present so
this shouldn't impact anybody except for gnome-clocks (where this change
will be fixing a bug) and gnome-terminal.
https://bugzilla.gnome.org/show_bug.cgi?id=699259
ext3 and ext4 (for quite some time) with default mount options don't
need fsync() to ensure safety of replace-by-rename. Stop doing that for
these filesystems.
Note: this patch also impacts ext2, which is probably not safe, but I
don't know of any way to check ext2. vs the others because they all have
the same magic numbers (short of opening /proc/mount).
This patch assumes that if BTRFS_SUPER_MAGIC is defined then so will be
EXT3_SUPER_MAGIC.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
OS X's getaddrinfo() only supports IPv6 scope IDs that are interface
names, not numbers. So use if_indextoname() to get the name of an
interface and construct an address using that.
https://bugzilla.gnome.org/show_bug.cgi?id=700123
Use a normal write() system call instead of fdopen() and fwrite().
This will definitely work on UNIX system and should work on Windows as
well...
As an added bonus, we can use g_close() now as well.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
g_file_set_contents() sets a GError in the event of various failures
that count occur. It uses g_filename_display_name() in order to get the
filename to include in the messages.
Factor out the error handling to make it easier to allocate the display
name only when we need it (instead of allocating it every time).
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Extents-based filesystems like knowing in advance how much data will be
written to a file in order to prevent fragmentation. If we have it, use
posix_fallocate() before writing data in g_file_set_contents().
https://bugzilla.gnome.org/show_bug.cgi?id=701560
