1. 19 Aug, 2019 1 commit
  2. 18 Aug, 2019 1 commit
  3. 16 Aug, 2019 1 commit
  4. 15 Aug, 2019 1 commit
  5. 12 Aug, 2019 1 commit
  6. 08 Aug, 2019 3 commits
    • Sam Thursfield's avatar
      afc: Use g_debug() instead of g_print() for log output · 5af74b51
      Sam Thursfield authored
      Daemons shouldn't be printing directly to stdout, but should be using
      the normal GLib logging system. The messages output by this daemon
      will not show by default, but setting `G_MESSAGES_DEBUG=GVFS-AFC` in
      the environment will cause them to appear.
    • Peter Keresztes Schmidt's avatar
      fuse: cleanup {read,write}_stream functions · 3b1188ce
      Peter Keresztes Schmidt authored
      Remove unnecessary while loop since g_input_stream_read_all
      and g_output_stream_write_all guarantee that all data is
      read/written when exiting successfully.
    • Peter Keresztes Schmidt's avatar
      fuse: Remove max_write limit · b4047cdf
      Peter Keresztes Schmidt authored
      Since we moved to fuse 3 big_writes are enabled by default.
      There is no need to manually specify max_write anymore since the
      set value is actually smaller than the libfuse default.
      Let libfuse figure out the right value.
      This increses the transfer speed from 31MiB/s to 43MiB/s between
      my system and a SMB share.
  7. 05 Aug, 2019 2 commits
  8. 04 Aug, 2019 1 commit
  9. 28 Jul, 2019 1 commit
  10. 26 Jul, 2019 2 commits
  11. 25 Jul, 2019 1 commit
    • segfault3's avatar
      udisks2: Change display name for crypto_unknown devices · 258e2344
      segfault3 authored
      The udisks id_type crypto_unknown is used for devices which are possibly
      In udisks, this uncertainty is conveyed to the user by using the long name
      "Possibly encrypted", and the short name "Encrypted?".
      GVfs used to display all devices with id_usage == "crypto" as
      "Encrypted". This commit instead uses the string "Possibly Encrypted" if
      id_type == "crypto_unknown".
  12. 24 Jul, 2019 3 commits
    • Daniel Mustieles García's avatar
      Updated Spanish translation · 98d3ca97
      Daniel Mustieles García authored
    • Mayank Sharma's avatar
      google: Disable deletion of non-empty directories · 07a4695b
      Mayank Sharma authored
      Earlier, we were deleting a directory irrespective of whether it
      was empty or not. This would cause a permanent deletion of the
      folder on Drive, and accidental deletions could be catastrophic.
      `g_file_delete()` states that if a directory is supposed to be deleted,
      the job should only carry forward to completion if the directory is
      empty, else it should error out. We fix this behaviour of delete
      operation in google backend by conforming to GIO's documentation.
    • Mayank Sharma's avatar
      google: Fix crashes when deleting if the file isn't found · 63d97b19
      Mayank Sharma authored
      Currently in delete operation, if the entry gets resolved but parent
      resolution fails, the jump to `out` label (while handling error) will
      cause the existing entry's ref_count to decrease by 1 (since `out`
      label calls g_object_unref on entry).
      We fix the issue by removing g_object_unref from `out` label and
      suitably unreffing the entry.
  13. 22 Jul, 2019 1 commit
  14. 19 Jul, 2019 3 commits
    • Goran Vidović's avatar
      Update Croatian translation · f7e06c59
      Goran Vidović authored
    • Iñigo Martínez's avatar
      build: Remove `rpath` parameter · 7920cd38
      Iñigo Martínez authored
      Target executables used as monitors do not depend on `libgvfscommon`
      or `libgvfsdaemon`, which are `gvfs` libraries installed outside of
      the default library directory.
      Due to this reason, they don't need to set `rpath` parameter.
    • Robby Workman's avatar
      daemon/meson.build: define gvfs_rpath for libgvfsdaemon.so · f361857c
      Robby Workman authored
      On Slackware development branch with gvfs-1.40.2, I just noticed this:
        # ldd /usr/lib64/gvfs/libgvfsdaemon.so | grep "not found"
      	libgvfscommon.so => not found
      After some backtracking, it seems that this first occurred in the
      switchover from autotools to meson in the 1.36.x --> 1.38.x bump.
      Big thanks to Cogitri in #gnome/irc.gnome.org for the patience and
      assistance with troubleshooting this.
      Signed-off-by: default avatarRobby Workman <rworkman@slackware.com>
  15. 18 Jul, 2019 1 commit
    • Mayank Sharma's avatar
      google: Fix issue with stale entries remaining after rename operation · 95511d5d
      Mayank Sharma authored
      Currently, whenever we perform a rename operation, we set the `entry`'s
      title to new display name, but at the time of removal of this entry from
      cache, we still use the newer title. Hence, each time rename is done, a
      single stale entry remains. This commit fixes the issue by reverting
      back the title to the original display name of `entry` and then
      performing a removal from cache.
      Fixes: #410
  16. 15 Jul, 2019 5 commits
    • Matthew Leeds's avatar
      ProxyVolumeMonitor: Don't leak a GVfsDBusDaemon · 12b238a3
      Matthew Leeds authored
      In g_proxy_volume_monitor_register() we create a GVfsDBusDaemon object
      (which is also of type GDBusProxy) but never free it. This causes there
      to be a dangling reference to the singleton GDBusConnection object used
      by the GDBusProxy for the rest of the lifetime of a process that uses a
      gvfs function such as g_file_new_for_path(). With the recent changes I
      made to GLib[1], that extra reference leads to a warning after a 30
      second delay in g_test_dbus_down().
      So this commit frees the GVfsDBusDaemon object after it has served its
      purpose in g_proxy_volume_monitor_register(), which fixes the test
      failure I'm seeing in another project.
      This is consistent with how we handle GDBusProxy objects in most of the
      rest of gvfs, but there are two places where they are leaked:
      1. in g_proxy_volume_monitor_constructor(), but that object appears to
      be intended to live forever, so it's unclear what should be done there
      2. in meta_tree_get_metadata_proxy(), but there the proxy is a static
      variable so it's unclear when it should be freed
      If you try to reproduce this leak, note that if gio takes its "lazy
      loading" code path in g_io_modules_scan_all_in_directory_with_scope(),
      this g_proxy_volume_monitor_register() function may not be executed. So
      I had to change an if condition so that we would always call
      g_type_module_use(). That lazy loading only happened when I built and
      installed gvfs myself rather than using the distribution's package.
      [1] glib!963
    • Ondrej Holy's avatar
      Post release version bump · 3236c26f
      Ondrej Holy authored
    • Ondrej Holy's avatar
      Update NEWS for 1.41.4 release · b3e1ff2e
      Ondrej Holy authored
    • Ondrej Holy's avatar
      Update info about reporting bugs · 5237de9f
      Ondrej Holy authored
      README file still points to bugzilla.gnome.org instead of gitlab.gnome.org.
      Let's fix that and add some info about reporting security issues also.
    • Ondrej Holy's avatar
      google: Do not enumerate volatile entries if title matches id · 1afee5ad
      Ondrej Holy authored
      Currently, the volatile entry is enumerated if its title matches id
      of another entry. But we don't want to enumerate volatile entries
      to not confuse our clients. Let's add simple check to prevent this.
  17. 12 Jul, 2019 1 commit
  18. 11 Jul, 2019 4 commits
  19. 10 Jul, 2019 1 commit
  20. 09 Jul, 2019 1 commit
    • Mayank Sharma's avatar
      google: Check ownership in is_owner() without additional HTTP request · 212f531e
      Mayank Sharma authored
      Earlier, we were fetching ACL feed of an entry and then checking the
      ownership by comparing account identity with elements from this feed.
      This was slow due to Network IO being performed while checking ownership.
      We now use GDataAuthors on a GDataEntry to get the list of "owners" of
      the file. We then use the GoaObject stored on GDataGoaAuthorizer to get
      the account which is being used by GDataService. Finally, we take the
      email address of account and compare them to check the ownership. This
      method now runs without anymore additional network requests.
  21. 28 Jun, 2019 1 commit
  22. 19 Jun, 2019 2 commits
  23. 06 Jun, 2019 2 commits