Restoring non-empty folders spawns warning - leaves copy behind

Bug #1687075 reported by Kev Bowring on 2017-04-28
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
thunar
Fix Released
Medium
thunar (Ubuntu)
Undecided
Unassigned

Bug Description

Empty folders after deleting and restoring from trash works without warning.

Folders with contents are restored AND left in trash, with a warning about modifying.

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: thunar 1.6.11-1
ProcVersionSignature: Ubuntu 4.10.0-19.21-generic 4.10.8
Uname: Linux 4.10.0-19-generic x86_64
ApportVersion: 2.20.4-0ubuntu4
Architecture: amd64
CasperVersion: 1.380
CurrentDesktop: XFCE
Date: Fri Apr 28 17:23:11 2017
LiveMediaBuild: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: thunar
UpgradeStatus: No upgrade log present (probably fresh install)

Created attachment 7095
warning screenshot

Empty folders after deleting and restoring from trash works without warning.

Folders with contents are restored AND left in trash, with a warning about modifying.

Have 1.6.11 with patch from 13481 installed locally.

Kev Bowring (flocculant) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in thunar (Ubuntu):
status: New → Confirmed

I can confirm this on 17.04 and 16.04 LTS. This is how the warning looks like - http://i.imgur.com/RSI1TJi.png

Default focus is on Cancel and when I click it folder is restored AND it stays in the trash. Retry doesn't do anything (same warning again), and skipping it restores the folder and removes it from the trash.

David Pearson (akxwi-dave) wrote :

can also confirm affects daily AA iso..

Retry - this option restores the folder to it's source, but respawns the warning dialogue

Cancel - restores the folder to source

Skip all/Skip - restores the folder to source

Changed in thunar:
importance: Unknown → Medium
status: Unknown → Confirmed
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1687075

tags: added: iso-testing

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.

In , Gitbot (gitbot) wrote :

vc-01 referenced this bugreport in commit 92b29110322e27489709ce293b58455884576ca5

Restoring non-empty folders spawns a warning about modification/restores folder and leaves copy in Trash (bug #13535)

https://git.xfce.org/xfce/thunar/commit?id=92b29110322e27489709ce293b58455884576ca5

Thanks alot for report and patch! And sorry for the late reply !

@vc-01
As you suggested, I added G_FILE_COPY_ALL_METADATA.
I as well think it is reasonable to keep all metadata when a file is moved ( AFAIK this flag anyhow only make sense if the copy + delete fallback is used, so before the patch it would have no effect )

Fixed now for thunar master, to be released as 1.8.0

In , Gitbot (gitbot) wrote :

vc-01 referenced this bugreport in commit ccc1ea458273eec2e238c34118e4460631349434

Restoring non-empty folders spawns a warning about modification/restores folder and leaves copy in Trash (bug #13535)

https://git.xfce.org/xfce/thunar/commit?id=ccc1ea458273eec2e238c34118e4460631349434

As well fixed for xfce-4.12 branch ( will be released in thunar 1.6.15 )

Changed in thunar:
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunar - 1.6.14-1ubuntu1

---------------
thunar (1.6.14-1ubuntu1) bionic; urgency=medium

  * debian/patches/lp1687075.patch:
    - Fix restoring non-empty folders from trash (LP: #1687075)

 -- Sean Davis <email address hidden> Sat, 10 Mar 2018 06:57:16 -0500

Changed in thunar (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.