Project

General

Profile

Feature #6254

Make it easy to empty Trash on persistent volume

Added by alant over 5 years ago. Updated 9 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Persistence
Target version:
-
Start date:
09/03/2013
Due date:
% Done:

67%

QA Check:
Feature Branch:
Type of work:
Code
Blueprint:
Starter:
No
Affected tool:

Description

There is currently no way of emptying the trash stored in the persistent volume without interacting with hidden files. This issue should be fixed.

When it is fixed, the FAQ bullet should be removed.


Subtasks

Bug #6255: Research how to fix persistence Trash handlingResolved

Bug #6285: Make sure Trash patches proposed upstream get reviewed and mergedConfirmedalant

Bug #6286: Implement a workaround for Persistent's trash handlingRejectedalant


Related issues

Related to Tails - Feature #7083: Explain how to empty the trash of the persistent volume Resolved 04/14/2014
Related to Tails - Feature #10064: Warn when persistent volume is getting full Confirmed 08/20/2015
Related to Tails - Feature #14544: Spend software developer time on smallish UX improvements In Progress 08/31/2018
Duplicated by Tails - Bug #11261: Trash folder invisible and 'inaccessible' when persistence is enabled Duplicate 03/18/2016

History

#1 Updated by intrigeri over 5 years ago

  • Subject changed from Make it easy to empty persistent volume trash to Make it easy to empty Trash on persistent volume

#2 Updated by sajolida over 5 years ago

That's definitely related to GNOME bug 604015, since the Trash on a separate USB stick is handled correctly: its content is merged into the Trash presented by Nautilus from the main home folder for example.

https://bugzilla.gnome.org/show_bug.cgi?id=604015

Reading this report, I think the bad behavior we experience with the persistent storage is relate to how it is mounted. It says:

« The trash backend currently only tracks trashed files on "user interesting" mounts -- those that g_unix_mount_is_system_internal() returns FALSE for. This is approximately equal to "stuff mounted in /media/". »

I tried to unmount it from /home/amnesia/Persistent and bind it onto /media/Persistent but it doesn't work either. It would have been too easy of course.

Anyone feels like exploring g_unix_mount_is_system_internal() and finding a way of having it return FALSE for our Persistent folder?

#3 Updated by intrigeri over 5 years ago

Anyone feels like exploring g_unix_mount_is_system_internal() and finding a way of having it return FALSE for our Persistent folder?

Even if we can workaround this now, once we get better boot medium
protection in Wheezy (#5518), then it's likely that the
workaround breaks.

There might be some conflict between what we want for security (that
is, see the boot medium as a system one, which bilibop possibly does,
or not yet?) and what we want for better UX :(

#4 Updated by alant over 5 years ago

« The trash backend currently only tracks trashed files on "user interesting" mounts -- those that g_unix_mount_is_system_internal() returns FALSE for.

Verified, see [[https://git.gnome.org/browse/gvfs/tree/daemon/trashlib/trashwatcher.c]]

Anyone feels like exploring g_unix_mount_is_system_internal() and finding a way of having it return FALSE for our Persistent folder?

I had i look at [[https://developer.gnome.org/gio/2.29/gio-Unix-Mounts.html#g-unix-mount-is-system-internal]] and [[https://git.gnome.org/browse/glib/tree/gio/gunixmounts.c]], especially guess_system_internal and g_unix_is_mount_path_system_internal.

I fail to see why it wouldn't be FALSE for our case.

#5 Updated by alant over 5 years ago

I found that `/live/persistence/*_unlocked` is not considered as internal by GIO `g_unix_mount_is_system_internal`.

However GIO (responsible for putting the file to trash) and GVFS (responsible for looking for trashes) disagrees on the location of the trash in our specific case:
- when one trashes a file from Persistent, GIO's `g_file_trash` calls `g_local_file_trash` that lookup each parent directory until it finds a device and thus find `/home/amensia/Persistent` and creates a `.Trash-1000` there;
- GVFS trashlib get mounts from GIO's `g_unix_mounts_get`, that explicitely ignore bind mounts and thus returns `/live/persistence/*_unlocked` but not `/home/amensia/Persistent`. It thus look for `.Trash-1000` in `/live/persistence/*_unlocked`.

#6 Updated by sajolida about 5 years ago

  • Related to Feature #7083: Explain how to empty the trash of the persistent volume added

#7 Updated by BitingBird over 4 years ago

  • Description updated (diff)

#8 Updated by intrigeri about 3 years ago

  • Duplicated by Bug #11261: Trash folder invisible and 'inaccessible' when persistence is enabled added

#9 Updated by intrigeri over 1 year ago

A user on XMPP was affected by this problem again today. Good candidate for UX improvements we may want to prioritize higher, perhaps?

#10 Updated by u over 1 year ago

  • Assignee set to sajolida
  • QA Check set to Info Needed

See intrigeri's previous comment: do we want to prioritize this UX wise?

#11 Updated by sajolida over 1 year ago

  • Assignee deleted (sajolida)
  • QA Check deleted (Info Needed)

Sure, problems are meant to be fixed. But we don't really know the cost and don't have someone to fix that so my say is of little value.

#12 Updated by intrigeri 9 months ago

  • Related to Feature #10064: Warn when persistent volume is getting full added

#13 Updated by sajolida 9 months ago

  • Tracker changed from Bug to Feature

#14 Updated by sajolida 9 months ago

  • Related to Feature #14544: Spend software developer time on smallish UX improvements added

Also available in: Atom PDF