[Xfce-bugs] [Bug 13535] Restoring non-empty folders spawns a warning about modification/restores folder and leaves copy in Trash

[bugzilla-daemon at xfce.org]

https://bugzilla.xfce.org/show_bug.cgi?id=13535

vc-01 <vlado.chren at inmail.sk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vlado.chren at inmail.sk

--- Comment #2 from vc-01 <vlado.chren at inmail.sk> ---
Created attachment 7096
  --> https://bugzilla.xfce.org/attachment.cgi?id=7096&action=edit
[PATCH] Allow GIO copy/delete fallback for file restore from Trash

Error message showed on attached the picture is very probably set in
gvfsbackendtrash.c:trash_backend_delete()

if (!is_toplevel)
    g_set_error_literal (&error, G_IO_ERROR, G_IO_ERROR_PERMISSION_DENIED,
        _("Items in the trash may not be modified"));

*Analysis*
This happens when thunar restores file using schemes (e.g. trash:///trasheddir
-> file:///restoredir), sets flag G_FILE_COPY_NO_FALLBACK_FOR_MOVE to
g_file_move(), then g_file_move() "wants" to fallback to copy/delete because
move between different mount points is not supported, and then thunar fallbacks
to internal manual copy/delete file by file. Finally trying delete file which
is not a top level file in trash:// is not permitted by gvfs (see above).

*Solution*
I don't know why this flag is set globally here for every file move a then
thunar internally implements this copy/delete fallback feature.

Hence in this patch, I removed flag G_FILE_COPY_NO_FALLBACK_FOR_MOVE for trash
restore operation only. I would also think about adding
G_FILE_COPY_ALL_METADATA later. It looks reasonable to me.

In 'pcmanfm' (file manager), flags used in this operations are
G_FILE_COPY_NOFOLLOW_SYMLINKS | G_FILE_COPY_ALL_METADATA.

In thunar flags are (were) G_FILE_COPY_NOFOLLOW_SYMLINKS |
G_FILE_COPY_NO_FALLBACK_FOR_MOVE.

-- 
You are receiving this mail because:
You are the assignee for the bug.