- May 21, 2015
-
-
- Nov 10, 2014
-
-
Ondrej Holy authored
When an application tries to save a larger key-value pair than the size of the journal, it triggers the journal to be flushed to make space for the entry and the operation is then retried, but it never fits, and the loop continues forever. This patch removes the endless retry loop and retries the operation only once after the flush. We know that there isn't enough space for the entry if it fails after the flush. https://bugzilla.gnome.org/show_bug.cgi?id=637095
-
- Feb 05, 2014
-
-
Shankar Prasad authored
-
- Dec 13, 2013
- Nov 28, 2013
-
-
I've seen a ton of bug reports where the backend crashes due to operations executing after an unmount begins. I think it's a sufficient solution to check the unmount flag that we already have and then immediately abort the operation. Generally, this is only seen with operations that are initiated implicitly like do_query_info or do_enumerate, but I've added the protection to all operations for consistency.
-
- Nov 22, 2013
-
-
Some servers send empty resourcetype nodes or don't send the node at all for regular files (the spec says that it defaults to empty). Set the file type to regular by default. https://bugzilla.gnome.org/show_bug.cgi?id=706798
-
- Nov 13, 2013
-
-
Alexander Larsson authored -
Alexander Larsson authored
-
Use an unsigned char to avoid implementation-defined behavior of a right shift. Shift by 4 rather than 8 to get the second half of a byte. https://bugzilla.gnome.org/show_bug.cgi?id=711457
-
If the daemon is killed during the fallback copy, it is possible that proxy is NULL which causes a segfault when unrefing it. Use g_clear_object() instead. https://bugzilla.gnome.org/show_bug.cgi?id=711454
-
If the symlink path already exists, return the correct error code of G_IO_ERROR_EXISTS. https://bugzilla.gnome.org/show_bug.cgi?id=710935
-
-
Without the big_writes option, fuse uses a block size of 4096 bytes which results in poor write performance. So use the big_writes option to write blocks up to 64KiB in size. https://bugzilla.gnome.org/show_bug.cgi?id=652540
-
-
-
Alexander Larsson authored
also, don't query for the file size unless required for SEEK_END https://bugzilla.gnome.org/show_bug.cgi?id=709432
-
Alexander Larsson authored
We created a GSource, attached it to a non-default main context and then removed it via g_source_remove, which removed the source with the same id on the main context, which typically was the X fd, causing everything to stop working! Non-default main contexts must use g_source_destroy() https://bugzilla.gnome.org/show_bug.cgi?id=708744
-
Instead of failing in read() with ENOTSUPP after the lseek on a nonseekable stream succeeds, make the lseek fail with ESPIPE, as it should. This is important for applications which test the return value of lseek to determine if the file descriptor is seekable.
-
When running multithreaded, fuse can issue readahead requests out of order which can cause subsequent reads to fail with ENOTSUPP (if seeking backward is not supported on the stream). Force readahead to occur in order to prevent this problem.
-
Since fh->pos is already incremented by n_bytes_skipped, check if offset == fh->pos. This error was hidden by the fact that the operation is retried when -EIO is returned. When it was retried, the stream was already in the correct position and so no seek operation was required.
-
In gvfsjobopenforread.c, the dbus method returns a value in create_reply which eventually results in a GVfsJobRead job to be sent to the backend. This could happen before the "new-source" signal is emitted. If this happens, the job is not queued because the "new_job" signal would not have been connected to a job source yet. The read then hangs because the GVfsJobRead is lost. This is hit often when performing large smb transfers (see https://bugzilla.gnome.org/show_bug.cgi?id=697782 and https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1075923). It can be reproduced by putting a small sleep before the g_signal_emit_by_name call. Fix this by emitting the "new-source" signal *before* the dbus method value is returned. This ensures that the "new_job" signal is set up before any further jobs are sent. Note that the same problem and solution applies for gvfsjobopenforwrite.c.
-
-
-
Alexander Larsson authored
There was a deadlock that could happen on client disconnect in peer_connection_closed(). If the cancelled job immediately called back into job_finished_callback() we would deadlock on daemon->mutex. So, make sure we cancel jobs without holding the lock, just like handle_cancel() does. https://bugzilla.gnome.org/show_bug.cgi?id=708816
-
Alexander Larsson authored
This code is not used anymore https://bugzilla.gnome.org/show_bug.cgi?id=708744
-
Alexander Larsson authored
There is no need to register for monitor evens on all dbus connections, just the one we send the request on. https://bugzilla.gnome.org/show_bug.cgi?id=708744
-
Alexander Larsson authored
There is no need to listen to messages on other connections than the one we sent the request on. In fact, doing so is bad as it can cause locking issues as per bug 708721. https://bugzilla.gnome.org/show_bug.cgi?id=708744
-
When building the file attribute table info, use thumbnail paths in $XDG_CACHE_DIR/thumbnails/large in addition to $XDG_CACHE_DIR/thumbnails/normal. Failing to do this would cause an application that creates large thumbnails by default to never find any value for G_FILE_ATTRIBUTE_THUMBNAIL_PATH, with no G_FILE_ATTRIBUTE_THUMBNAILING_FAILED set, which might cause the application to either think thumbnailing is still in progress, or blindly requeue thumbnail operations in a loop. Large thumbnails are generally preferred, so we now default to the path of a large thumbnail (in case both are present). Fixes: https://bugzilla.gnome.org/688685
-
- Nov 02, 2013
-
-
victory authored
-
- Sep 23, 2013
-
-
Andika Triwidada authored
-
- Jun 19, 2013
-
-
- Jun 14, 2013
-
-
Alexander Larsson authored
-
Alexander Larsson authored
-
Alexander Larsson authored
This was reading the size in the wrong place *sizep, not *(sizep-1), plus the out of bounds checks were wrong. https://bugzilla.gnome.org/show_bug.cgi?id=637095 (cherry picked from commit 5a4f9e6a) Conflicts: metadata/metatree.c
-
Now that we can be in charge of mounts even if we have the shadow mount infrastructure, we should export it so that tracking of the associated GDaemonMount works correctly. https://bugzilla.gnome.org/show_bug.cgi?id=696279 (cherry picked from commit 7aa0c533)
-
Some volume monitors, like gnome-online-accounts, want their mount implementation to be called even though the volume has an activation root. Allow them to advertise so using the expansion fields of the volume DBus representation. https://bugzilla.gnome.org/show_bug.cgi?id=696279 (cherry picked from commit 97a4246b)
-
If two files have two different origins (say, one from g_mount_get_root() and one from g_file_new_for_uri()), the mount_spec they use could expose a different mount_prefix, even if the represent the same URI and network object. This in particular fixes the handling of shadow mounts for dav (which rewrites the mount_spec during mount to find the right prefix) https://bugzilla.gnome.org/show_bug.cgi?id=696279 (cherry picked from commit bf50158c)
-
Related to https://bugs.freedesktop.org/show_bug.cgi?id=65130 (cherry picked from commit f389246b)
-
- Jun 06, 2013
-
-
- May 21, 2013
-
-
Matthias Clasen authored
-
