commit 186e1ae1fea8b2222d5c6a4bfdf53bf2b660a7d9
Author: Tomas Bzatek <tbzatek@redhat.com>
Date: 2013-04-16
Update NEWS for 1.16.1 release
M NEWS
commit af5e3d4f409e1fdef13bc9454d015d23401ecdf4
Author: OKANO Takayoshi <kano@na.rim.or.jp>
Date: 2013-04-16
l10n: Update Japanese translation
M po/ja.po
commit 53c901ec9b9837e04665d9b354c51bf09cca29a4
Author: Richard Stanislavský <kenny.vv@gmail.com>
Date: 2013-04-14
Updated slovak translation
M po/sk.po
commit 2875ba2137ad5279317271e9b9c10a9e1e9fcd5c
Author: Bruce Cowan <bruce@bcowan.me.uk>
Date: 2013-04-06
Updated British English translation
M po/en_GB.po
commit 22fc427fc8871a613af1926a56887fb050f7051e
Author: Gheyret Kenji <gheyret@gmail.com>
Date: 2013-04-06
Updated Uyghur translation
Signed-off-by: Gheyret Kenji <gheyret@gmail.com>
M po/ug.po
commit e0941e88ffdd3b4d89e8d2db9dabbb86ff9d81e1
Author: Alexander Larsson <alexl@redhat.com>
Date: 2013-04-05
daemons: Tweak read sizes
Make sure we never read more than one page unless requested on
the first
read. This helps for e.g. sniffing and gstreamer (which reads in
4k blocks
with seeks inbetween).
Also, further limit the max size request, because 512k seems very
ridicoulus.
M daemon/gvfsreadchannel.c
commit c9b8fc094d7a95386641901957cca890d5345aa1
Author: Alexander Larsson <alexl@redhat.com>
Date: 2013-04-05
Fix readahead behaviour
We were constantly adding extra readahead operations that were
not really
needed. A single readahead is necessary to get the read operations
pipelined (see comment). Also, avoid readahead for the first read
to handle random access i/o better.
https://bugzilla.gnome.org/show_bug.cgi?id=697289
M daemon/gvfsreadchannel.c
commit 3df8e843690d39e8437930e8350a4aaecb199729
Author: Alexander Larsson <alexl@redhat.com>
Date: 2013-04-05
GVfsJobError: Return TRUE in try
This fixes a warning and a potentially useless call of do() method in
a thread.
M daemon/gvfsjoberror.c
commit 5e614ee502ced670a681e33ea2d0c8363d9068ca
Author: Alexander Larsson <alexl@redhat.com>
Date: 2013-04-04
remove debug spew
M daemon/gvfsjoberror.c
commit e1be69f4bcec01c007016ae33dbb48514b09ba75
Author: Alexander Larsson <alexl@redhat.com>
Date: 2013-04-04
GVfsChannels: Verify that replies are for the right serial
We might be getting replies for old cancelled operations which
we need to ignore.
https://bugzilla.gnome.org/show_bug.cgi?id=675181
M client/gdaemonfileinputstream.c
M client/gdaemonfileoutputstream.c
commit 6141549ed4660e888fb6438434c789db47b6f665
Author: Alexander Larsson <alexl@redhat.com>
Date: 2013-04-04
channel: Unqueue cancelled requests
We put a channel request on the output buffer and start writing, but
if the write is cancelled on the first call (i.e. no partial writes)
we abort immediately without ever writing the request.
However, if we do this we also need to unqueue the request from
the output
buffer, as otherwise this will be sent with the next operation. This
can be problematic for seeks as the seek generation is then not
in sync.
https://bugzilla.gnome.org/show_bug.cgi?id=675181
M client/gdaemonfileinputstream.c
M client/gdaemonfileoutputstream.c
M daemon/gvfschannel.c
commit d667f6fe956d8661710f9fe5ad3e54d9b24aa04a
Author: Alexander Larsson <alexl@redhat.com>
Date: 2013-04-04
Fix daemon crash when cancelling channel operations
The error handling in gvfschannel.c:start_queued_request() when
there was an error creating the job or when the request was cancelled
caused problems. It didn't set current_job, yet it called
g_vfs_channel_send_error() which eventually resulted in a
call to send_reply_cb which crashed as it assumed current_job
was set.
Also, not returning TRUE for started_job when we sent an error
is problematic as we then could start the next job which caused
us to have two outstanding jobs on the same channel mixing things up
badly.
https://bugzilla.gnome.org/show_bug.cgi?id=675181
M daemon/Makefile.am
M daemon/gvfsbackend.h
M daemon/gvfschannel.c
A daemon/gvfsjoberror.c
A daemon/gvfsjoberror.h
commit a376e0808c2e8212462025d8065e60d091995d36
Author: Tomas Bzatek <tbzatek@redhat.com>
Date: 2013-04-03
gvfschannel: Return proper error if we're out of free fds
In case of too many open files within the process the
g_vfs_channel_init() call fails on socketpair and subsequent
g_vfs_channel_steal_remote_fd() call returns -1 for the fd.
Then g_unix_fd_list_append() hits the assert and doesn't set an
error we're dereferencing afterwards.
This patch doesn't solve the lack of free fds situation and since glib
heavily depends on it it would fail somewhere else. We're just fixing
the segfault and returning nicer error.
Based on a fix suggested by Stephen M. Webb
https://bugzilla.gnome.org/show_bug.cgi?id=696713
M daemon/gvfschannel.c
M daemon/gvfsjobopenforread.c
M daemon/gvfsjobopenforwrite.c
commit e526c310c8186509165108153b187013ded106d5
Author: Bastien Nocera <hadess@hadess.net>
Date: 2013-03-14
Fix compiler warnings
https://bugzilla.gnome.org/show_bug.cgi?id=695834
(cherry picked from commit 421ce4a6b4526047fde9d8d039a66b520eb09f3f)
M client/gvfsfusedaemon.c
M common/gvfsmountinfo.c
M daemon/gvfsafpvolume.c
M daemon/gvfsbackenddav.c
M daemon/gvfshttpinputstream.c
M metadata/meta-get-tree.c
M monitor/goa/goavolume.c
M monitor/udisks2/gvfsudisks2volume.c
commit 5cce0efe8605f73d8cc1499e39c873fdc1a0d4af
Author: Bastien Nocera <hadess@hadess.net>
Date: 2013-03-31
obexftp: Fix crasher due to missing D-Bus threads support
Spotted by Serge Gavrilov <serge@pdmi.ras.ru>
The GDbus port removed the need for us to initialise
libdbus' threads support, and commit
7d4bd61385cd56db5507ee31b14724244b637da4
removed the last call to it.
However, the obexftp backend still hasn't fully been ported
to GDbus, and needs this threading support. Re-add it directly
in the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=693574
M daemon/gvfsbackendobexftp.c
commit adbe1bade2d3d9ba41c29d745cfa5ae433063554
Author: Philip Langdale <philipl@overt.org>
Date: 2013-03-23
Daemon: Ensure monitors are not prematurally finalized.
If a monitor is being cleaned up due to the backend disappearing,
we could see the monitor being finalized as a result of removing
a subscriber, leading to a segfault as it continues to access
its internal state.
https://bugzilla.gnome.org/show_bug.cgi?id=696479
M daemon/gvfsmonitor.c
commit e9ba3d8951d83c1e3be14ba6ed60b72906ffff0f
Author: Krishnababu Krothapalli <kkrothap@redhat.com>
Date: 2013-03-26
Updated Telugu Translations
M po/te.po
commit 4f9c0df5e761adca0107fe3dcfcd3054a5a6c5ed
Author: Krishnababu Krothapalli <kkrothap@redhat.com>
Date: 2013-03-26
Updated Telugu Translations
M po/te.po
commit 1dbba65340ad096bf18d1995edd58ba37d89eede
Author: Shankar Prasad <svenkate@redhat.com>
Date: 2013-03-26
Updated kn translations
M po/kn.po
commit 92abf64e33686bb2ae715fa7abde7f1d38c13ac5
Author: Tomas Bzatek <tbzatek@redhat.com>
Date: 2013-03-25
Post release version bump
M configure.ac