1. 10 Jan, 2019 1 commit
  2. 19 Dec, 2018 3 commits
  3. 18 Dec, 2018 3 commits
  4. 17 Dec, 2018 14 commits
  5. 14 Dec, 2018 3 commits
  6. 13 Dec, 2018 1 commit
  7. 11 Dec, 2018 4 commits
  8. 05 Dec, 2018 1 commit
  9. 26 Nov, 2018 1 commit
  10. 23 Nov, 2018 2 commits
  11. 15 Nov, 2018 1 commit
  12. 13 Nov, 2018 3 commits
    • Will Thompson's avatar
      tests/g-file-info-filesystem-readonly: remove output stream stuff · a2f32f6a
      Will Thompson authored
      This test is intended to verify the fix for
      https://bugzilla.gnome.org/show_bug.cgi?id=787731, which was that
      g_file_query_filesystem_info() would return stale information for the
      mount. After replacing a read-only mount with a read-write mount, this
      test used to only fail if G_FILE_ATTRIBUTE_FILESYSTEM_READONLY was TRUE
      and yet the file could be opened for writing. In particular, if (due to
      a test bug) the file really was still on a read-only filesystem, the
      test would pass.
      
      Now that we have fixed that bug in the test, we can make a stronger
      assertion.
      a2f32f6a
    • Will Thompson's avatar
      tests/g-file-info-filesystem-readonly: unmount lazily · 5b106cdc
      Will Thompson authored
      fusermount -z behaves like umount --lazy, which is documented thus:
      
      > Detach the filesystem from the file hierarchy now, and clean up all
      > references to this filesystem as soon as it is not busy anymore.
      
      Without this, the call to `fusermount -u` often fails with:
      
        /usr/bin/fusermount: failed to unmount /home/wjt/src/gnome/glib/_build/dir_bindfs_mountpoint: Device or resource busy
      
      which causes the subsequent call to bindfs to fail:
      
        fuse: mountpoint is not empty
        fuse: if you are sure this is safe, use the 'nonempty' mount option
      
      It's not clear what is causing the mount to be busy. Inserting a
      g_usleep (100 * 1000) before the calls to `fusermount -u` also works to
      make the problem go away, but for the purposes of this test the
      important point is that the mount is detached from the directory, for
      which a lazy unmount is fine.
      
      Fixes #1590.
      5b106cdc
    • Will Thompson's avatar
      tests/g-file-info-filesystem-readonly: assert subcommands succeed · 3821ba06
      Will Thompson authored
      In practice, fusermount -u often fails:
      
        /usr/bin/fusermount: failed to unmount /home/wjt/src/gnome/glib/_build/dir_bindfs_mountpoint: Device or resource busy
      
      which causes the subsequent calls to bindfs to fail:
      
        fuse: mountpoint is not empty
        fuse: if you are sure this is safe, use the 'nonempty' mount option
      
      This may or may not cause the current test run to fail, but it reliably
      causes a repeat run of the test to fail. This change causes the current
      run to fail instead.
      3821ba06
  13. 12 Nov, 2018 1 commit
    • INSUN PYO's avatar
      gio, tests: fix leak of dbus connection. · bf1a2d70
      INSUN PYO authored
      /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
      1- Start server
         gio/tests/.libs/gdbus-example-peer --server --address unix:abstract=/tmp/peer/myaddr
      
      2- Check the open fds for server process
         lsof -a -p 8253
         ..................
         gdbus-exa 8253 imran    0u   CHR      136,1      0t0        4 /dev/pts/1
         gdbus-exa 8253 imran    1u   CHR      136,1      0t0        4 /dev/pts/1
         gdbus-exa 8253 imran    2u   CHR      136,1      0t0        4 /dev/pts/1
         gdbus-exa 8253 imran    3u  0000        0,9        0     6602 anon_inode
         gdbus-exa 8253 imran    4u  unix 0xf1005680      0t0   966830 @/tmp/peer/myaddr
      
      3- Run the client
         gio/tests/.libs/gdbus-example-peer --address unix:abstract=/tmp/peer/myaddr
      
      4- Check the open fds for server process again
         lsof -a -p 8253
         ..................
         gdbus-exa 8253 imran    0u   CHR      136,1      0t0        4 /dev/pts/1
         gdbus-exa 8253 imran    1u   CHR      136,1      0t0        4 /dev/pts/1
         gdbus-exa 8253 imran    2u   CHR      136,1      0t0        4 /dev/pts/1
         gdbus-exa 8253 imran    3u  0000        0,9        0     6602 anon_inode
         gdbus-exa 8253 imran    4u  unix 0xf1005680      0t0   966830 @/tmp/peer/myaddr
         gdbus-exa 8253 imran    5u  unix 0xf1004280      0t0   965811 @/tmp/peer/myaddr
         gdbus-exa 8253 imran    6u  0000        0,9        0     6602 anon_inode
      
      5- Please note the fd '5u' which is created when client makes connection but even when the client goes down, the descriptor is still there..
      ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
      
      https://bugzilla.gnome.org/show_bug.cgi?id=734281
      bf1a2d70
  14. 10 Nov, 2018 1 commit
    • Cosimo Cecchi's avatar
      gdbusproxy: make g-name-owner property useful with unique names · 47be0f7a
      Cosimo Cecchi authored
      Currently, GDBusProxy:g-name-owner only notifies changes to the unique
      name owner of the remote object in case the proxy was constructed for a
      well-known name.
      That sounds like an artificial restriction, and it's convenient to
      connect to notify::g-name-owner if a proxy instance has already been
      created for an unique name, instead of additionally using
      g_bus_watch_name() to track the owner.
      
      To fix this, always connect to NameOwnerChanged after the proxy is
      initialized, instead of only doing so when the proxy was constructed for
      a well-known name.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=791316
      #1310
      47be0f7a
  15. 09 Nov, 2018 1 commit