After questioning the semantics of flush on IRC, it seemed necessary to
clarify what flushing is supposed to do. The Linux man page for fflush()
seemed to cover it perfectly, so I just copied it.
I did not add the "via the underlying write mechanism" part as that in
my opinion is not something subclasses should need to guarantee.
This patch makes GFileMonitor to emit EVENT_CHANGES_DONE_HINT when
EVENT_CREATED is emitted but the file is not opened for writing.
On file moves across different mounted volumes, inotify will always emit
IN_CREATE and IN_CLOSE_WRITE (plus other events).
This translates into GIO's _EVENT_CREATED and _EVENT_CHANGES_DONE_HINT.
On file moves across the same mounted volumes, inotify will emit
IN_MOVED_FROM/IN_MOVED_TO which will be translated into
_EVENT_DELETED/_EVENT_CREATED GIO's side. No _EVENT_CHANGES_DONE_HINT is
emited afterwards.
Under such circumstances a file indexer does not know when actually the
file is ready to be indexed, either waiting too much or triggering the
indexing twice. On small devices it's not advisable.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=640077
Bug-NB: NB#219982
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Tomas Bzatek <tbzatek@redhat.com>
Previously, this would fail the assertion
"connection->initialization_error != NULL" after the label "out".
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=665067
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <davidz@redhat.com>
This is useful in peer-to-peer connections.
With minor changes by David Zeuthen <davidz@redhat.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=662718
Signed-off-by: David Zeuthen <davidz@redhat.com>
A g_input_stream_read_async() implementation can't call
g_input_stream_read() on itself directly because it will fail because
the pending flag is already set. So fix that by invoking the vmethod
directly rather than calling the wrapper. Likewise with
GMemoryOutputStream.
Add a test to gio/tests/memory-input-stream.c to catch read_async
failures in the future.
g_file_set_attribute() also permits a NULL value for value_p, and requires it
to be NULL to unset it. Also fix the wrong variable name in the documentation.
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
This new API allows requesting multiple pieces of information about a
particular action in one go and also simplifies the burden for
GActionGroup implementations -- they need not implement all the separate
APIs now.
This is the ISO C sense of undefined behaviour, in which
works-by-coincidence, critical warning, abort, demons-fly-out-of-your-nose
are all valid implementations.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662208
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <davidz@redhat.com>
This was a regression in commit f41178c6c: flush_async_data wasn't
necessarily NULL in the "don't flush" case.
Also move initialization of these variables up so that it's
unconditional, since that's easier to verify than checking
that each branch gets it right.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=664617
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If we can't get on the session bus, just behave like a normal non-unique
application.
This turns out to be remarkably easy to implement and lets us avoid
adding a 'dummy' backend.
Add a test for this case as well.
Idea from Zachary Dovel.
https://bugzilla.gnome.org/show_bug.cgi?id=651997
This happens to work at the moment (because GDBusWorker.frozen is a
gboolean and not just a 1-bit bitfield), but isn't right: the gboolean
ends up with values 0 or G_DBUS_CONNECTION_FLAGS_DELAY_MESSAGE_PROCESSING
(which is more than 1).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=664558
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <davidz@redhat.com>
These might even make useful public API if they grew a Windows
implementation, but for now they can be Unix-only test API.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
We didn't previously flush in a couple of cases where we should have
done:
* a write is running when flush is called: we should flush after it
finishes
* writes have been made since the last flush, but none are pending or
running right now: we should flush the underlying transport straight
away
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
This makes it easier to schedule a flush, by putting it on the same code
path as writing and closing.
Also change message_written to expect the lock to be held, since all
that's left in that function either wants to hold the lock or doesn't
care, and it's silly to release the lock immediately before calling
message_written, which just takes it again.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
When we use this function to schedule a flush, it'll be called
with the lock held. Releasing and immediately re-taking the lock would
be pointless.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
maybe_write_next_message now also closes, and I'm about to make it
consider whether to flush as well, so its name is increasingly
inappropriate. Similarly, write_message_in_idle_cb is a wrapper around
it which could do any of those things.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
If the user calls flush_sync() with no messages in the queue, but an
async write call pending, then we ought to flush after that async write
returns (although we don't currently do that). If it was an async close
or flush that was pending, there's no need to flush (again) afterwards.
So, we need to distinguish.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
