Created attachment 7096
[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.
Created attachment 7096
[PATCH] Allow GIO copy/delete fallback for file restore from Trash
Error message showed on attached the picture is very probably set in gvfsbackendtras h.c:trash_ backend_ delete( )
if (!is_toplevel) error_literal (&error, G_IO_ERROR, G_IO_ERROR_ PERMISSION_ DENIED,
g_set_
_("Items in the trash may not be modified"));
*Analysis* /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).
This happens when thunar restores file using schemes (e.g. trash:///trasheddir -> file://
*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.