Debian Patches
Status for gvfs/1.59.1-1
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| metadata-nuke-junk-data.patch | Nuke the metadata file if magic blob is wrong Related to https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/405432, https://gitlab.gnome.org/GNOME/gvfs/-/issues/255, https://gitlab.gnome.org/GNOME/gvfs/-/issues/122, https://bugzilla.gnome.org/show_bug.cgi?id=750113, https://bugzilla.gnome.org/show_bug.cgi?id=598561 marked as obsolete -smcv |
Christian Kellner <gicmo@gnome.org> | yes | 2009-11-04 | ||
| dont-crash-on-null-job.patch | Don't try to announce the finish of a NULL job. 2013-11-04 comment upstream: "This is not reproducible on current git master so it must have been fixed up in the meantime." |
Michael Terry <mterry@ubuntu.com> | yes | upstream | vendor, Ubuntu | 2012-04-11 |
| handle-inactive-vfs.patch | Don't crash when creating volume monitors if the VFS was never initialized | Michael Terry <mterry@ubuntu.com> | no | upstream | vendor, Ubuntu | 2012-04-11 |
| ref-jobs-in-thread.patch | make sure to keep a ref to jobs while they run in a thread | Michael Terry <mterry@ubuntu.com> | no | vendor, Ubuntu | 2012-04-12 | |
| 0008-Skip-the-umockdev-test.patch | Skip the umockdev test The trace is out of date & needs to be re-recorded by somebody who has the hardware. |
Sebastien Bacher <seb128@ubuntu.com> | not-needed | upstream | vendor, Ubuntu | 2018-03-19 |
| 0009-gvfs-test-Increase-timeout-to-10s.patch | gvfs-test: Increase timeout to 10s In normal operation some operations - particularly unmounting - can take quite a while. Let's give things a bit longer before giving up. Patch originally by Andreas Hasenack <andreas.hasenack@canonical.com> |
Iain Lane <iain@orangesquash.org.uk> | yes | upstream | 2018-03-19 | |
| udisks2-Re-order-volume-changed-signal-to-be-emitted-afte.patch | udisks2: Re-order volume-changed signal to be emitted after other updates Consider a mount event. update_all() first updates the volume object, which would immediatly emit a "volume-changed" signal, and only later emits the "mount-added" signal. That means that a GVolumeProxy upon receiving a "changed" signal does not actually know the new state of the mount yet. This still kindof used to work before 14dc69de, because a notification from udisksd would arrive last, after setting up the mount point, which would make gvfs emit "volume-changed" *again*, like so: * GUnixMountMonitor::mounts-changed -> update_all() -> emit volume-changed -> emit mount-added * UDisksBlockProxy::notify:userspace-mount-options -> update_volume_on_event -> emit volume-changed After 14dc69de instead, we process the udisksd event first and only schedule update_all() for 100ms later, so the signal order looks like this: * UDisksBlockProxy::notify:userspace-mount-options -> update_volume_on_event -> emit volume-changed * GUnixMountMonitor::mounts-changed -> update_all() -> emit volume-changed -> emit mount-added We should instead schedule the "volume-changed" to be emitted last, which we can achieve by a simple g_idle_add. This patch was rejected upstream in favour of a larger rework, but that still needs to be finished and merged. Let's fix the bug for now. |
Alessandro Astone <alessandro.astone@canonical.com> | yes | 2025-11-18 | ||
| udisks2-Fix-memory-corruption-with-duplicate-mount-paths.patch | udisks2: Fix memory corruption with duplicate mount paths Calling g_hash_table_insert on a key that already exists in the table frees the old value and the *new* key, thus leaving the old key pointing to free'd memory. g_hash_table_replace instead frees the old value and key together and inserts the new value and key into the table. |
Alessandro Astone <alessandro.astone@canonical.com> | no | https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/297 | 2026-02-03 |