diff options
| author | Ondrej Holy <oholy@redhat.com> | 2020-09-24 10:19:22 +0200 |
|---|---|---|
| committer | Ondrej Holy <oholy@redhat.com> | 2020-09-24 10:51:39 +0200 |
| commit | 5c0bc82e7c22fd1fa88b243c53d6c677ed19541f (patch) | |
| tree | aedb229c733734228af48f26c39ff215f20772cf /client | |
| parent | b03b7955cf25e863c1aac2853ddaf647bfb70ea8 (diff) | |
| download | gvfs-5c0bc82e7c22fd1fa88b243c53d6c677ed19541f.tar.gz | |
trash: Do not fail when G_FILE_COPY_NO_FALLBACK_FOR_MOVE is usedwip/oholy/trash-performance
Restoring files from the trash folder is slow in Nautilus as it attempts
to do it recursively. This is because G_IO_ERROR_NOT_SUPPORTED is
returned from g_file_move when G_FILE_COPY_NO_FALLBACK_FOR_MOVE flag is
used. The error is returned from client-side for pull/push operations
after commit 2e765449 as in the most cases the copy-and-delete approach
is really used there. But the problem is that it is not in all
cases, like in the trash backend case, where the native move operation
is used in fact. Let's handle the G_FILE_COPY_NO_FALLBACK_FOR_MOVE flag
directly in the backends, but not in the trash backend.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1589
Diffstat (limited to 'client')
| -rw-r--r-- | client/gdaemonfile.c | 8 |
1 files changed, 0 insertions, 8 deletions
diff --git a/client/gdaemonfile.c b/client/gdaemonfile.c index 2a8c1511..f11cf91c 100644 --- a/client/gdaemonfile.c +++ b/client/gdaemonfile.c @@ -2689,14 +2689,6 @@ file_transfer (GFile *source, return FALSE; } - if (!native_transfer && remove_source && - (flags & G_FILE_COPY_NO_FALLBACK_FOR_MOVE)) - { - g_set_error_literal (error, G_IO_ERROR, G_IO_ERROR_NOT_SUPPORTED, - _("Operation not supported")); - return FALSE; - } - if (!native_transfer && local_path == NULL) { /* This will cause the fallback code to be involved */ |