commit 8f94df31bfb8939d9986308f723ce01ff898d1ba
Author: Ondrej Holy <oholy@redhat.com>
Date: 2014-08-15
Update NEWS for 1.21.90 release
M NEWS
commit 540b03f9a73f58b1a1237b84ae1d453c4ac37a5f
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-08-12
gvfs-save: Allow specifying G_FILE_CREATE_REPLACE_DESTINATION
Allow specifying G_FILE_CREATE_REPLACE_DESTINATION when using
gvfs-save
with the -u flag or --unlink. I chose this because "unlink"
represents
what G_FILE_CREATE_REPLACE_DESTINATION does in principle: it
unlinks the
destination before replacing it, thereby losing any permissions
or other
attributes of the file.
https://bugzilla.gnome.org/show_bug.cgi?id=734695
M man/gvfs-save.xml
M programs/gvfs-save.c
commit aae5c91460a36f091384a4b3bcbb8cb70f33f135
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-06-07
dav: Send enumerate success earlier
Send a "success" response earlier when enumerating to allow infos
to be
sent incrementally rather than batched up until the end.
https://bugzilla.gnome.org/show_bug.cgi?id=734695
M daemon/gvfsbackenddav.c
commit 32a1e8d6fc55fa525deb85d8fc93497e8b74e832
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-06-02
afp: Fix some memory leaks
https://bugzilla.gnome.org/show_bug.cgi?id=734695
M daemon/gvfsafpserver.c
M daemon/gvfsbackendafp.c
commit 32e9db1387588f37da8b6825f3c7f70ad8c49ef1
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-08-12
daemon: Fix a memory leak
https://bugzilla.gnome.org/show_bug.cgi?id=734695
M daemon/gvfsjobenumerate.c
commit bcd8b846329309bc997fd8116534352140e6142b
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-08-12
computer: Fix a memory leak
https://bugzilla.gnome.org/show_bug.cgi?id=734695
M daemon/gvfsbackendcomputer.c
commit 3d20db3249bfd5a9aaab89f5d09e948d1bc28d4f
Author: Tom Tryfonidis <tomtryf@gmail.com>
Date: 2014-08-11
Updated Greek translation
M po/el.po
commit 32983ccd7e3d15e6071464236376abf0b855b904
Author: Philip Langdale <philipl@overt.org>
Date: 2014-08-07
MTP: Fix error semantics for do_pull/do_push/do_make_directory
There are a bunch of semantic inconsistencies in the existing
implementations of these functions, when compared with the GIO
docs for making dirs and copying files.
This change fixes those problems, and also ensures that in the
pull/push cases, the destination is deleted at the last possible
moment, in the case of overwrites.
Also, certain other methods had their error code changed from
NOT_REGULAR_FILE to PERMISSION_DENIED when an operation is
attempted on a storage. This leads to less surprising errors
for users.
https://bugzilla.gnome.org/show_bug.cgi?id=734305
M daemon/gvfsbackendmtp.c
commit 63899f1a7e6aa286a97e82e99ae036d597cee748
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-07-31
ftp: Only free connection if non-NULL
Only attempt to free the connection if it is non-NULL, to prevent
warnings like the following:
** (process:30854): CRITICAL **: g_vfs_ftp_connection_free: assertion
'conn != NULL' failed
The connection can be NULL if g_vfs_ftp_connection_new is cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=591054
M daemon/gvfsftptask.c
commit 9bd1bd2c7a96b69ef4de956eb04d3bb58f748c0e
Author: Benjamin Otte <otte@redhat.com>
Date: 2014-08-11
ftp: Also mark connection as unusable on G_IO_IN
There is data waiting on an FTP connection and we didn't request it.
It's not ours and we have no way to clear it. Just makr this
connection
as unusable.
Most likely this is the server notifying us about a timeout or other
connection abort, so it's a good idea to treat it as an error anyway.
Also includes a new debug message for when we mark a connection as
unusuable and why.
https://bugzilla.gnome.org/show_bug.cgi?id=591054
M daemon/gvfsftpconnection.c
commit 648c433bfbc88aaa757a0adb86b20ca3c986108b
Author: Benjamin Otte <otte@redhat.com>
Date: 2014-08-11
ftp: Check connection is usable when acquiring
Qhen acquiring a cached connection, it might have timeout'ed or
otherwise not be available anymore. We don't want these connection
errors to propagate into the job we're handling and instead just
acquire
the next connection.
https://bugzilla.gnome.org/show_bug.cgi?id=591054
M daemon/gvfsftptask.c
commit 232d6d76029dc1cbc0c76c2459f9db26b7717d28
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-08-09
fuse: Don't map EISDIR to EXDEV when renaming
vfs_rename incorrectly maps EISDIR to EXDEV when renaming. However,
EISDIR occurs when the source is a file and the destination is a
directory and it shouldn't be remapped. (G_IO_ERROR_WOULD_RECURSE is
mapped to EXDEV instead.)
https://bugzilla.gnome.org/show_bug.cgi?id=734568
M client/gvfsfusedaemon.c
commit 4341cf2b36e408c3598bc533d9510ff6ff5b0f84
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-08-09
fuse: Add GError to errno mappings for G_IO_ERROR_WOULD_RECURSE
and G_IO_ERROR_WOULD_MERGE
This patch adds the following GError to errno mappings to
errno_from_error():
G_IO_ERROR_WOULD_RECURSE -> EXDEV
G_IO_ERROR_WOULD_MERGE -> ENOTEMPTY
The first mapping is required to allow 'mv' to rename/move a
directory in a gvfs-fuse directory that belongs to a backend
without support for a native move operation. In such cases,
g_file_move() returns G_IO_ERROR_WOULD_RECURSE, which needs to
be mapped to -EXDEV in order for mv to fall back to recursive
copy & delete operation.
Similarly, G_IO_ERROR_WOULD_MERGE is returned when trying to
move/merge two non-empty directories. By mapping it to -ENOTEMPTY,
the error message returned by 'mv' becomes ": Directory not empty"
instead of generic ": Input/output error".
https://bugzilla.gnome.org/show_bug.cgi?id=734568
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M client/gvfsfusedaemon.c
commit be4d7fa3b44a8c195bf6e19cf2a44ff9440ffc07
Author: Ondrej Holy <oholy@redhat.com>
Date: 2014-02-27
daemon: consider all jobs excepting unmount as blocking processes
User can wait to finish all jobs (not only those with opened channel)
before unmount to avoid potencial crashes.
https://bugzilla.gnome.org/show_bug.cgi?id=710986
M daemon/gvfsbackend.c
M daemon/gvfsbackend.h
M daemon/gvfsdaemon.c
M daemon/gvfsdaemon.h
M daemon/gvfsjobunmount.c
commit 0aafc320c4278ccb0469d2aea981ab03db3cbfab
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-07-26
gphoto: Set mtime when pulling
Commit 86162bbe4b09 ("gphoto2: Implement pull support") failed to set
the modification time of the destination file when implementing pull
support.
Fix this by setting the modification time on the destination file
(only
the mtime in seconds needs to be set since this is the only time info
the gphoto supports).
https://bugzilla.gnome.org/show_bug.cgi?id=733469
M daemon/gvfsbackendgphoto2.c
commit 1fdcb2b67e740b13a16cfa9cbdd1c87276af8d9a
Author: Inaki Larranaga Murgoitio <dooteo@zundan.com>
Date: 2014-08-07
Updated Basque language
M po/eu.po
commit 4fff3674b9c909a5d2838bdbc96ba98724d10d56
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-08-04
mtp: do_open_for_read() should fail on a directory
This is a fix for bug #729628: the GIO open-read-write-close
fallback for copy/move operation on MTP volumes works correctly
for files, but fails for directories - in particular, it creates
a file with the destination name, then fails with "libmtp error:
Unknown error." This happens because the fallback first attempts
to open the source as a file, and if it succeeds, proceeds to
create destination file and copy the contents via series of
reads/writes.
For directories, do_open_for_read() should fail with
G_IO_ERROR_IS_DIRECTORY, which in tun causes GIO to create the
destination as directory, and then copy its contents over.
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M daemon/gvfsbackendmtp.c
commit e949e7b9918c5867a2948eb6c641171bae4e99f8
Author: MarMav <mavridou@gmail.com>
Date: 2014-08-04
Updated Greek translation
M po/el.po
commit c7bb2e1f5341d03cbc7b195d756f49fdf7a0f0f5
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-08-03
mtp: improve validation of received thumbnail/sample data in
do_open_icon_for_read()
With my tablet, the call to LIBMTP_Get_Thumbnail() in
do_open_icon_for_read() sometimes succeeds with return code 0, but
returns size 0 and NULL data pointer. Thus, subsequent read
operations return no data, and Nautilus ends up with invalid
preview icon.
This patch adds validation of returned data size, and treats size
0 same as if the call failed - reporting no icon data to be
available and causing Nautilus to read the actual file content to
obtain the preview icon.
Also, LIBMTP_destroy_filesampledata_t() is now called regardless
whether LIBMTP_Get_Representative_Sample() call succeeds or not.
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M daemon/gvfsbackendmtp.c
commit fbb887f56f3b28fe03ef2bdad96c114cf8a2661c
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-08-03
mtp: convert icon id using hexadecimal base instead of decimal one
This is a fix for regression introduced by 30697fe32d47 ("mtp: in
debug traces, print IDs as hexadecimal values instead of decimal
ones"), which changed format of icon id constructed in
get_file_info() from decimal to hexadecimal, while the inverse
conversion in do_open_icon_for_read() remained unchanged, using
decimal base.
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M daemon/gvfsbackendmtp.c
commit 12c95538d84eaa17b17e82c01bc1608570c4102d
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-08-03
afp: Remove old TODO
https://bugzilla.gnome.org/show_bug.cgi?id=734194
M daemon/gvfsafpvolume.c
commit 2e3eee275a97abf4d6055c06683f04c7d8f3f7ca
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-08-03
mtp: Fix two harmless warnings
Fix two warnings introduced by be000ea91e90 ("MTP: Emit delete events
when unmounting.").
M daemon/gvfsbackendmtp.c
commit e9c320e49cace543450b961af32ea7ffeb8d512f
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-08-03
afp: Don't retry read if connection closes
Don't retry the read if the remote host closes the connection.
Instead,
exit (semi-)gracefully with exit(0) and exit with an error if
there was
an actual error.
https://bugzilla.gnome.org/show_bug.cgi?id=710490
M daemon/gvfsafpconnection.c
commit a4016460538ea8be22aa0d8289922b389a93ef78
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-08-03
afp: Try to prevent idle disconnects
Some servers (e.g. OS X 10.8) disconnect clients who don't respond to
server notifications. Prevent this by sending FPGetVolParms, as the
spec suggests.
https://bugzilla.gnome.org/show_bug.cgi?id=734194
M daemon/gvfsafpconnection.h
M daemon/gvfsafpvolume.c
commit 5b4fdbeb6b1e19aa1bbc3824c5955ee2f9c1f85b
Author: Piotr Drąg <piotrdrag@gmail.com>
Date: 2014-07-31
doap: add <programming-language>
M gvfs.doap
commit 2481998a6e42b0a15c850a6f7c61a5471cc3e0d6
Author: Olav Vitters <olav@vitters.nl>
Date: 2014-07-30
doap category core
M gvfs.doap
commit 7ebbf005fb52f3b2fe362fbf297ca1557b8c09d8
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-07-28
mtp: make remove_cache_entry_by_id() remove all matching entries,
not just the first one
With the recently added on-demand post-fixing of storage names,
corner cases can occur in which we end up with multiple cache
entries that have the same storage id and item id, but different
paths.
In particular, this happens upon change of post-fixing requirement,
i.e., when a second storage that has same description as the first
one is either added or removed. In such cases, the contents of the
first storage might end up with two sets of cache entries, one where
storage name is post-fixed and one is not. If afterwards an
OBJECT_REMOVED event is received, only the first cache entry is
removed, which may or may not cause Nautilus to correctly remove
the file/folder.
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M daemon/gvfsbackendmtp.c
commit 6eb6853bfca43d714f48ca5edd676feaec357326
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-07-28
mtp: added support for OBJECT_ADDED event
This patch adds support for OBJECT_ADDED event, which is emitted
when a file or a folder is created on the device. When such an
event is received, its path is determined by first looking up the
parent ID and appending object's name to it; the path and IDs are
added to cache, and create event is emitted, causing clients (for
example Nautilus) to display the new file/folder without having to
refresh the display of parent folder.
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M daemon/gvfsbackendmtp.c
commit be000ea91e90186bb6f1031348e33d5b9025251a
Author: Philip Langdale <philipl@overt.org>
Date: 2014-07-26
MTP: Emit delete events when unmounting.
Although it would seem obvious that a mount disappearing should
invalidate any file references in clients, recent versions of
Nautilus will keep open windows around, showing all the files that
were there at the time of the unmount.
So, clearly we need to emit these events to get it to clean itself
up.
M daemon/gvfsbackendmtp.c
commit f92fbc0f481f41c04fd61fa4c061c418cc3a0c8c
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-07-26
mtp: implemented support for LIBMTP_EVENT_STORE_REMOVED
This patch adds support for LIBMTP_EVENT_STORE_REMOVED, so that if a
storage is removed, its entry and those of its children are
automatically removed. For each such entry, delete event is also
emitted.
With this patch, the corresponding storage disappears from Nautilus
as soon as the SD card is unmounted on device. Similarly, if Nautilus
is located in the storage or one of its sub-folders, the window gets
properly closed after the storage is removed.
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M daemon/gvfsbackendmtp.c
commit 0f84e858fd236412fda7c5d3837fefb79ac442e1
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-07-26
mtp: removed the faulty g_free(new_name) at the end of
do_set_display_name()
The new_name string is passed to add_cache_entry(), which assumes full
transfer; therefore, freeing the string manually causes issues further
down the line.
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M daemon/gvfsbackendmtp.c
commit 766a77bfd304b6741993527e25338480af0861cd
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-07-24
mtp & gphoto2: add missing newlines at the end of debug messages
Commit edd777b1e675f9328aa00934651b4763783930a1 modified DEBUG() macro
and, by replacing combination of g_vfprintf(stderr, message, args) and
g_fprintf(stderr, "\n") with a g_logv(G_LOG_DOMAIN, G_LOG_LEVEL_DEBUG,
message, args), caused a lack of trailing newlines in debug messages.
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M daemon/gvfsbackendgphoto2.c
M daemon/gvfsbackendmtp.c
commit 449a4b878695de6e545fadaa7fe846d7deb64acc
Author: Ross Lagerwall <rosslagerwall@gmail.com>
Date: 2014-07-01
http: Use a global SoupSession rather than per-backend
Use a global SoupSession rather than a per-backend so that idle
connections are reused appropriately. This prevents a process running
out of file descriptors due to connections stuck in a CLOSE_WAIT
state.
It also has the side-effect of limiting the maximum number of
concurrent
connections because libsoup's max-conns property is respected, fixing
bug 576460.
(Reapplying now that #732783 and #732925 have been fixed.)
https://bugzilla.gnome.org/show_bug.cgi?id=732090
M daemon/gvfsbackendhttp.c
commit be4fc6f8e8a33e5d6c84d4e2959b3f6d4377f442
Author: Christophe Fergeau <cfergeau@redhat.com>
Date: 2014-07-01
http: Remove use of SoupSessionSync/SoupSessionAsync
Since libsoup 2.42.0, SoupSessionSync/SoupSessionAsync are deprecated,
and replaced by direct use of SoupSession as described on
https://developer.gnome.org/libsoup/stable/libsoup-session-porting.html
This commit removes use of SoupSessionSync/SoupSessionAsync and
adjusts
the code according to the advice in the doc above:
- we only need one SoupSession instance as sync/async calls are
made depending on the SoupSession method we use, not depending
on the instance type
- SoupSession already comes with a SoupProxyResolverDefault, we don't
need to add it ourselves
- SoupSession already comes with a SoupContentDecoder, we don't
need to add it ourselves
- SoupSession:use-thread-context is now unused and always set to TRUE,
so we don't need to change it
To prevent any changes in behavior, we set ssl-strict to FALSE.
(Patch updated by Ross Lagerwall)
(Reapplying now that #732783 and #732925 have been fixed.)
https://bugzilla.gnome.org/show_bug.cgi?id=708306
https://bugzilla.gnome.org/show_bug.cgi?id=732090
M daemon/gvfsbackenddav.c
M daemon/gvfsbackendhttp.c
M daemon/gvfsbackendhttp.h
commit 2744d498095aeca09308819bca42d0fe287523d0
Author: Simon McVittie <simon.mcvittie@collabora.co.uk>
Date: 2014-07-24
GDaemonMount: invalidate mount cache whenever we unmount a mount
Otherwise, the old mount info, and in particular the (D-Bus unique
name,
object path) pair representing it in its backend, will remain in
the cache until the backend process exits, which could take time.
Re-mounting and re-unmounting that mount would fail, because the
second Unmount() call would go to the unique name and object path of
the backend object that was destroyed by the first Unmount call,
not the backend object that is now responsible.
I'm using the Unmount reply rather than a signal, for thread-safety;
the mount cache is global, so if it was listening for the Unmounted
signal, that signal would be queued up for delivery to some
specific main-context, call it A. If another thread did the
umount/mount/unmount in main context B, before main context A was
dispatched, then the invalidation would be too late to help it.
This does not cover concurrent mount/unmount in two distinct main
contexts without any synchronization. However, if two threads in
main contexts B and C race to mount/unmount a share, then they're
sometimes going to lose anyway, and there isn't a great deal that
cache invalidation can do to help them.
M client/gdaemonmount.c
M client/gdaemonvfs.c
M client/gdaemonvfs.h
M client/gvfsdaemondbus.c
commit 64e51eb07cd6628991842c6be8eb276802b71154
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-07-23
mtp: use "storage-description (hex-storage-id)" storage name format
only when necessary
This patch implements on-demand post-fixing of storage description
with ID for storage name, i.e., only in cases, when description
itself is not unique.
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M daemon/gvfsbackendmtp.c
commit 8f97c9f56e7ad868393c4b344fa7b18ab6a65782
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-07-22
mtp: use "storage-description (hex-storage-id)" for storage name
instead of just "storage-description"
Storage description by itself is not unique, thus using it for storage
name on its own causes problems when multiple storages with the
same description are present (i.e., only one is listed and even that
one incorrectly referenced in some situations - [Bug 733465]). The
proposed storage name format is used both as name and display name.
On my TF701 with two SD cards, Nautilus now properly lists: "Internal
storage (10001)", "SD card (20001)" and "SD card (30001)", and the
corresponding URIs are:
mtp://[usb:001,005]/Internal storage (10001)
mtp://[usb:001,005]/SD card (20001)
mtp://[usb:001,005]/SD card (30001)
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M daemon/gvfsbackendmtp.c
commit 0d198d7ebab85a7fcddee036b731254556ba01f9
Author: Kjartan Maraas <kmaraas@gnome.org>
Date: 2014-07-23
Updated Norwegian bokmål translation.
M po/nb.po
commit 30697fe32d47d3c1f5694b56b06bc93095dd8851
Author: Rok Mandeljc <rok.mandeljc@gmail.com>
Date: 2014-07-19
mtp: in debug traces, print IDs as hexadecimal values instead of
decimal ones
Hexadecimal IDs are much easier to read than their decimal
counterparts.
Signed-off-by: Rok Mandeljc <rok.mandeljc@gmail.com>
M daemon/gvfsbackendmtp.c
commit 64797557badcf4d8729649a981566a19095658c2
Author: Enrico Nicoletto <liverig@gmail.com>
Date: 2014-07-18
Updated Brazilian Portuguese translation
M po/pt_BR.po
commit 97107976fdb965a1b0f5e9a82b63c71db0c68c1e
Author: Ondrej Holy <oholy@redhat.com>
Date: 2014-07-18
Post release version bump
M configure.ac