No more making db backups and snapshots read-only for the user

[victoryforce]

Making the backup unwritable for the user did not solve any real problem ("accidental damage of the backup" is a highly hypothetical scenario, not a real problem), but it caused problems for inattentive users.

#18124 protects against already created unwritable backups restored to read-only databases. Also, the comments in the mentioned PR contain links to reports where read-only databases were found to be the cause of problems.

If this PR will be merged for 5.0.1 it will reduce the number of incidents with read-only databases (given that protection against running darktable with such databases will only be in 5.2).

[wpferguson]

Making them read only prevents you from inadvertently deleting them. If you want to delete a read only database, you have to confirm it.

But, I do agree that most users using a backup copy probably don't realize that they have to make it writable.

[victoryforce]

Making them read only prevents you from inadvertently deleting them. If you want to delete a read only database, you have to confirm it.

As I wrote, this is a highly hypothetical scenario. Let's imagine a user who browsed to the darktable database location for some reason, and then inadvertently(!) deleted the backups.

If a user can inadvertently delete files in that location, they can also inadvertently delete all their other files: photos, documents, the entire contents of ~/. Then, using this logic, it makes sense to make all other files read-only.

But, I do agree that most users using a backup copy probably don't realize that they have to make it writable.

That's right. Even Linux users don't necessarily think to look at permissions. As for Windows users, it's a total fantasy.

[TurboGit]

Thanks, merged in master and 5.0.x branch.