https://bugzilla.gnome.org/show_bug.cgi?id=741895

This adds a public API where one can use to see whether the running version
of Windows where the code is run is at least the specified version, service
pack level, and the type (non-server, server, any) of the running Windows
OS.

This API is done as:
-GetVersion()/GetVersionEx() changed in the way they work since Windows 8.1
 [1][2], so a newer mechanism to check the version of the running Windows
 operating system is needed.  MSDN also states that GetVersion() might be
 further changed or removed after Windows 8.1.  This provides a wrapper for
 VerfyVersionInfo() as well in GLib for most cases, which was recommended
 in place of g_win32_get_windows_version() for more detailed Windows
 version checking.
-Provides an OS-level functionality check, for those that we don't need to
 venture into GetProcAddress(), and also to determine system API behavior
 changes due to differences in OS versions.

Also added a note for the g_win32_get_windows_version() API that...

We need to filter out gnetworkmonitornm.c in the MSVC Projects, as that is
UNIX-only code.

This is the bare minimal effort.  This seems not to crash immediately,
but it definitely needs some better testing.

The backend is not in good shape.  It could use some serious work.

Attach the GPollFileMonitor to the thread default main context instead
of the global default.

This matches the behaviour of the other file monitors.

The rules are now very simple: if we wake up and it's not interesting
then we sleep for a given amount of time (100ms) before checking again.

Also: introduce a smarter mechanism for getting all of the events
currently in the buffer.

Also: add a hashtable for move pairing

Return an "interesting" boolean from the event handler function on
GFileMonitorSource.

An event was "interesting" if it will result in a signal actually being
dispatched to the user.  It is "uninteresting" if it only hit an
already-dirty rate limiter.

We will use this information to do some backing off in the backends when
faced with a flood of uninteresting events.

CHANGES_DONE would delete the pending change record, ignoring the dirty
flag.  That means that a rate-limited CHANGED event would effectively be
dropped.  Fix up that inconsistency by reporting the CHANGED before the
CHANGES_DONE if the dirty bit was set.

We could accomplish what we want by simply reporting CREATED directly
followed by CHANGES_DONE.

We may want to add back _APPEARED some day and allow people to opt into
it separately via a GFileMonitorFlag if they really care about the
distinction.  It would certainly be nicer to allow the backends to
report this case with a distinct event type and have GFileMonitorSource
do the right thing.

...and try to send it for some common cases in inotify.

We're now abusing the WATCH_MOVES flag as a general "opt-in to new API".
That's bad.

Chun-wei Fan authored Jan 15, 2015 and Allison Karlitskaya committed Jan 16, 2015

The headers are used for G_TYPE_INITABLE and
G_NETWORK_MONITOR_EXTENSION_POINT_NAME, which led to undefined variables
if not included...

Remove all event merging and dispatch logic from GFileMonitor.  The only
implementation of GFileMonitor outside of glib is in gvfs and it already
does these things properly.

Get rid of GLocalDirectoryMonitor.  We will use a single class,
GLocalFileMonitor, for both directory and file monitoring.  This will
prevent every single backend from having to create two objects
separately (eg: ginotifydirectorymonitor.c and ginotifyfilemonitor.c).

Introduce GFileMonitorSource as a thread-safe cross-context dispatch
mechanism.  Put it in GLocalFileMonitor.  All backends will be expected
to dispatch via the source and not touch the GFileMonitor object at all
from the worker thread.

Remove all construct properties from GLocalFileMonitor and remove the
"context" construct property from GFileMonitor.  All backends must now
get the information about what file to monitor from the ->start() call
which is mandatory to implement.

Remove the implementation of rate limiting in GFileMonitor and add an
implementation in GLocalFileMonitor.  gvfs never did anything with this
anyway, but if it wanted to, it would have to implement it for itself.
This was done in order to get the rate_limit field into the
GFileMonitorSource so that it could be safely accessed from the worker
thread.

Add a couple of extra utility functions to GLocalFile so that we can
skip some memory copies (and skip the gvfs detection logic when choosing
which backend to use).  Expose the pre-existing "is_remote"
functionality.

With the "is_remote" functionality exposed, we can now move all
functions for creating local file monitors to a proper location in
glocalfilemonitor.c

Port the inotify backend to adjust to the changes above.  None of the
other backends are ported yet.

This mega-commit is a work in progress -- it should probably be broken
up.

Remove the hardwired 1 second event queue logic from inotify-kernel and
replace it with something vastly less complicated.

Events are now reported as soon as is possible instead of after a delay.

We still must delay IN_MOVED_FROM events in order to look for the
matching IN_MOVED_TO events, and since we want to report events in order
this means that events behind those events can also be delayed.  We
limit ourselves, however:

 - no more than 100 events can be delayed at a time

 - no event can be delayed by more than 10ms

https://bugzilla.gnome.org/show_bug.cgi?id=627285

Expose GContextSpecificSource so that things in GIO can use it directly.

Add support for a user_data area in the struct which will be helpful for
some intended use cases.

Also expose a way to emit a signal directly on a single source without
having to go through the group.

Add support for non-VOID__VOID signals to GContextSpecificGroup.

We keep the VOID__VOID case as a special optimised case by usual the
usual bit-stealing tricks.

GUnixMountMonitor was not threadsafe before.  It was a global singleton
which emitted signals in the first thread that happened to construct it.

Move it to a per-context singleton model where each GMainContext gets
its own GUnixMountMonitor.  Monitor for the changes from the GLib worker
thread and dispatch the results to each context with an active monitor.

https://bugzilla.gnome.org/show_bug.cgi?id=742599

Move this code to the correct part of the file.

While we're at it, drop an unused #define MOUNT_POLL_INTERVAL.

https://bugzilla.gnome.org/show_bug.cgi?id=742599

This is a large file with a lot of very complicated code in it.  Add
some fold markers to make things a bit more manageable.

https://bugzilla.gnome.org/show_bug.cgi?id=742599

Deprecate g_unix_mount_monitor_set_rate_limit() and turn it into a
no-op.

This function doesn't behave as advertised.  It only controls rate
limiting for filesystem-based monitors.  It has no impact over reporting
mount changes on Linux, for example, because those are based on polling
for changes in /proc (which doesn't use filesystem monitors).  It also
has no impact on Mac OS because a library interface is used there.

This was added in https://bugzilla.gnome.org/show_bug.cgi?id=521946 in
order to be used by HAL, which is effectively dead.  udisks no longer
uses this code at all.

https://bugzilla.gnome.org/show_bug.cgi?id=742599

This is a singleton, but we have a function called _new() to get it.
What's worse is that the documentation makes no mention of this, and
actually specifically says that a new monitor will be created each time.

https://bugzilla.gnome.org/show_bug.cgi?id=742599

https://bugzilla.gnome.org/show_bug.cgi?id=742599

Add a new internal helper called GContextSpecificGroup.

This is a mechanism for helping to maintain a group of context-specific
monitor objects (eg: GAppInfoMonitor, GUnixMountMonitor).

https://bugzilla.gnome.org/show_bug.cgi?id=742599

This new function is intended to be used for verifying that operations
on objects that belong to a given main context are only made from valid
places.

The usual rule is that the operations must be performed while the main
context is acquired, but an exception is made for the global default
main context so that things can be set up before running the main loop.

https://bugzilla.gnome.org/show_bug.cgi?id=742599

Add an internal function to get the name of a thread for display in
debugging messages.  We support reporting "the main thread" for the
thread that our ctor got run in (which is almost definitely what most
people would consider to be 'the main thread').

https://bugzilla.gnome.org/show_bug.cgi?id=742599

Include an example main() function, and include a link to the gettext
manual’s section on integrating gettext with build systems.

That should work as a complete reference for how to add i18n support to
an application.

https://bugzilla.gnome.org/show_bug.cgi?id=742972

Workaround found on
http://cnicholson.net/2009/03/stupid-c-tricks-dowhile0-and-c4127/

https://bugzilla.gnome.org/show_bug.cgi?id=742851

https://bugzilla.gnome.org/show_bug.cgi?id=741788

So that early adopters of new api have a version to target.

We were asking for properties on NM's dbus interface, but if NM is not
running then there won't be any. Check if the name has an owner before
doing anything to it.

https://bugzilla.gnome.org/show_bug.cgi?id=741653

AC_C_BIGENDIAN can return 'universal' as the result in the case that we
are trying to do a universal build on Mac OS.  This has to be opted into
explicitly by using multiple -arch CFLAGS.

Previously, we detected this result and fell back to doing our own check
based on the endianness of the build machine, hardcoding that.  This
means that universal builds might successfully build, but the binaries
would never actually run correctly on the 'opposite' arch.

This check was added because of a bug in the intial implementation of
this detection in autoconf, which was inappropriately identifying
non-macos compilers as 'universal'.  That was hitting ppc64 systems.
See https://bugzilla.redhat.com/show_bug.cgi?id=449944 for more info.

Commit b0e687ef42e21b1eb7af18c4eaebcd41b0bd5632 in autoconf ("Limit
AC_C_BIGENDIAN univeral checks to Mac OS X") solved this issue in 2008,
so let's remove our workaround.  For good measure, if we detect
"universal" in the result, error out.

https://bugzilla.gnome.org/show_bug.cgi?id=742548

Update config.h.win32.in and glibconfig.h.win32.in so that they will be
in-line with the ones that are produced with configure.ac, for use on
Windows builds.

Thanks to Philip Withnall for pointing out the changes needed to update
glibconfig.h.win32.in in bug 727829.

g_dbus_proxy_get_cached_property_names can return NULL if there are no
cached properties, so don't try to access them in that case.

Patrick Griffis authored Aug 16, 2014 and Allison Karlitskaya committed Jan 04, 2015

https://bugzilla.gnome.org/show_bug.cgi?id=734946