Do not delete user files!

[yakushabb]

Bug/Feature description

When I removed a library from Cozy, I didn't expect it to delete my files!

Why does Cozy need to delete user files? It should simply remove them from the Cozy library!

Even though the command is "Remove from library", the second question is:

msgid "Delete Audiobook?"
msgid "The audiobook will be removed from your disk and from Cozy's library."

I don't think users want their precious files to be deleted.

You can either create a command that says "Delete from disk" or add a checkbox like qBittorrent has.

"

Steps to reproduce

Try to remove a library! Please do not delete!

System Information

• Operating System: Fedora 40
• Installation source: Flatpak build from source code
• Version of cozy: 1.3.0

[rdbende]

I've brought this up some time ago, and @geigi said, that this behavior is intentional, though to me it seems like a workaround, not a feature. I'll link his reply if I can find it.

[yakushabb]

In that case, we need to make a few tweaks to the wording.

In GNOME, "remove" is typically used for a soft action that does not affect the actual files, while "delete" is used for a hard action that cannot be undone.

In Cozy, both terms are used interchangeably, and even I, as the translator of the project, cannot distinguish whether my files are going to be permanently deleted and lost a few files while testing the translation.

[yakushabb]

Also, it would be better to gather feedback from users. Alternatively, you can ask to GNOME Developers Whiteboards to get their point of view on which approach would be better for users.

[rdbende]

Also, it would be better to gather feedback from users. Alternatively, you can ask to GNOME Developers Whiteboards to get their point of view on which approach would be better for users.

I think there's no need for discussion in this topic, and I'm pretty sure that most people don't want this behavior. As I've said, the current solution is more of a workaround for a technical difficulty, rather than an actual feature, and it should be solved instead of discussing the design. I'll look into it this afternoon.

[geigi]

Sorry that some files where deleted which you didn't want to delete!
The current solution is indeed a workaround because of technical (and UX) reasons:

In the current state removing a file from Cozy would only work temporarily because during the next scan Cozy will have a look at all files in the configured directories and add every file which is not in the database yet.

A few years ago there was a blocklist implemented. If a file was removed from Cozy it was added to this blocklist. During import all files on this list where ignored. The user could also remove files again from this blocklist in the settings. This solution did cause it's own range of problems and misunderstandings which is why I removed it after some time. I think it was a UX pattern that was a bit unusual and complicated.

Using this mechanism as a basis I never had a good idea to solve this problem nicely. I think the current solution is how iTunes handled it back in the day. Maybe we could have a look at some other apps that also observe a directory and import everything in it and how they solve the problem, e.g. Jellyfin.

Another solution is, although it would change the UX quite a bit, to drop the observing of directories. The user would be able to import files or directories normally, we could even detect changes on imported files, but if new files get added to the directories we won't import them. That way the user can simply remove files from Cozy and keep them in the file system. But this solution also brings it's own challanges: what if the user renames a directory and issues a scan? The files won't be found anymore and the "new" ones won't be imported...

I'm not sure which solution we should go for.

[yakushabb]

IMHO, changing the wording of related strings might be the easiest way to handle this issue.

We can change the strings to something like the followings:

Suggestion 1

• Missing ellipses.
• Incompatible with GNOME HIG.
• The text body is too long.

---

Suggestion 2

• The title is obvious, the button is smilar with Nautilus

---

Suggestion 3

• The title is obvious, the button is too long.

---

Nautilus

[geigi]

I think so too that this is the easiest way currently. Thanks for your mockups! I quite like suggestion 2.

[rdbende]

Reopening, as I think it would be still better to have a blacklist rather than deleting files.