Warn the users that removing a persistent feature doesn't erase any data
We should warn the user that removing a software from the persistence by reconfiguring it doesn't erase its related data.
this warning should be in the persistence's documentation at least, but it could also be prompted when reconfiguring the persistent volume (with the path to the data ad a hint on how to wipe it ?)
#3 Updated by cbrownstein almost 3 years ago
I added to the documentation instructions on how to delete files left by deactivated features.
Specifically, I added the following language, with appropriate markup, to wiki/src/doc/first_steps/persistence/configure.mdwn:
The files for features reside in /live/persistence/TailsData_unlocked. The files can be deleted safely from this directory. In order to delete the files, you need administrative privileges.
For example, to delete the files corresponding to the GnuPG feature, execute in a root terminal rm -rf /live/persistence/TailsData_unlocked/gnupg.
#5 Updated by cbrownstein almost 3 years ago
I have updated the previously submitted patch.
It occurred to me the user might not know which files correspond to a given feature. For that reason, I created a link to the "Manually copying your persistent data to a new device" page, which lists each feature's corresponding folder.
#10 Updated by sajolida over 2 years ago
- Status changed from Confirmed to In Progress
- Assignee changed from sajolida to cbrownstein
- QA Check changed from Ready for QA to Dev Needed
- Feature Branch set to doc/12109-deactivate-persistent-features
Again, sorry for the huge delay and thanks for the patch.
I'm very happy with the language but I have some concerns regarding the
workflow. We usually try to avoid as much as possible having people to
do stuff on the command line; and when we do so, we try to keep it as
simple as possible. Here I see two options to make it easier:
- We could instruct people to only start Nautilus on the command line
(as we're doing in /doc/first_steps/persistence/copy). I think this
would make a big difference because the command line would be
shorter and people wouldn't have to adapt it to the folder that they
want to delete. Also, from my experience with people who are not
used to the command line, it's usually fine for them to copy paste
stuff in there blindly but one of the most confusing aspect is that
successful commands do not return anything (silence means
success). If we instruct them to open Nautilus it would have a
visual result and then they would be in a familir visual environment
to manipulate their files. Also, messing up with the command line
cannot end up in deleting all their data which is the case with your
proposal (imagine I type
- We could instruct people to use a regular Nautilus, open each of
these folders, and delete the files in there. These folders belong
amnesiaso they can delete their content (they cannot delete
the folders themselves because TailsData belongs to
Also, in terms of workflow:
- I'm always happy to review plans or workflows for instructions
before you write the actual text. You can comment on them on Redmine
- Now that you have the Contributor role on Redmine, you can edit the
metadata of tickets and, once you work is ready, you can assign it
to me and mark it as QA Check: Ready for QA.
- I understand from your well-formatted patches that you are familiar
with Git. So if you could host a copy of the repo somewhere that
would be a tiny bit easier for me to work with. If that's not much
more work for you... otherwise I'm fine with patches.
- I pushed your work in the branch
- You could also assign yourself some more end-user documentation
tickets if you want. I can make you some suggestions if you want :)
#11 Updated by cbrownstein over 2 years ago
- File 0001-Rewrite-instructions-to-use-nautilus-instead-of-comm.patch View added
- Assignee changed from cbrownstein to sajolida
- QA Check changed from Dev Needed to Ready for QA
I agree with you, for the reasons that you've stated, that using the command line to delete the persistent files isn't the best approach. I've rewritten the instructions to use
nautilus instead of the command line.
I'm attaching a patch; but I also have a branch (12109) at https://github.com/cbrownstein/tails/tree/12109
#12 Updated by sajolida over 2 years ago
- Assignee changed from sajolida to cbrownstein
Cool, thanks for the branch. I think the flow is much better now!
I adjusted 4 minor style issues in
doc/12109-deactivate-persistent-features again (50ec97ff2d..69d4668eb2). Please have a look and tell me if I can merge that.
If you plan to continue contributing more doc (I hope so!) and never read a documentation style guide, I highly recommend reading one. It helps spotting small issues of style that make technical writing shorter, more precise, more consistent, less ambiguous, and easier to read and translate for international readers. For the Tails documentation I refer to the GNOME Documentation Style Guide first because Tails is based on GNOME:
But also to the Apple Publication Style Guide and the Microsoft Manual of Style which all have their merits. Tell me if you want a copy of these :)