Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add trashbin cleanup and file versioning #612

Open
tio-trom opened this issue Oct 12, 2023 · 9 comments
Open

Add trashbin cleanup and file versioning #612

tio-trom opened this issue Oct 12, 2023 · 9 comments

Comments

@tio-trom
Copy link

tio-trom commented Oct 12, 2023

  'trashbin_retention_obligation' => 'auto, 30',
  'versions_retention_obligation' => 'auto, 30',

To the config file. This way we make sure that after 30 days the trashbin gets cleaned up. Also only keep file versioning for 30 days. I think it makes sense, else the server will fill up with trashed files and infinite number of file versioning.

@Bugsbane
Copy link

Clearing the trashbin certainly makes sense as the user has specifically chosen to delete items and then not restored them for a month. I would be hesitant to set versions to 30 days though, as this could be an unexpected behavior to users leading to data loss.

We don't want old versions filling up the server though, but I would suggest that this would be better served by setting it to not delete automatically by default, but suggesting this config setting in the Yunohost app description and app docs so server admins will be aware if it is set.

@tio-trom
Copy link
Author

The file versioning means to only keep 30 versions of the same file. I think that's also reasonable.

@Bugsbane
Copy link

Ah, ok. My mistake. I didn't read closely enough assumed it was also 30 days. In that case yes, both make good sense.

@Tagadda
Copy link
Member

Tagadda commented Oct 13, 2023

I don't think the default behavior is good for most use cases.
We could handle file retention through the config panel tho'

@lapineige
Copy link
Member

Yeah as user won't be able to notice the change that easily, I would be more in favour of a min 30 days of retention + delete only if space needed, which serves the purpose of freeing space when it grows too much, but keep a safe month of trashbin history.

@Tagadda
Copy link
Member

Tagadda commented Oct 13, 2023

Make admins notice the change easily, that's a mission for POST_UPGRADE.md o/

@tootbrute
Copy link

For those of you who found this issue because your hard drive if full...

More info about the trashbin options

You can edit your config.php file here:
/var/www/nextcloud/config/config.php

Another vote for please have a reasonable default like delete files older than 30 days.

@tomdereub tomdereub mentioned this issue Oct 4, 2024
1 task
@tomdereub
Copy link
Contributor

I also think it would be nice to have a default parameter that doesn't keep files indefinitely. I would propose :

  'trashbin_retention_obligation' => 'auto, 30',
  'versions_retention_obligation' => 'auto, 90',

I made a PR to add doc about this. The doc will have to be updated if the default yunohost parameter is changed.

@lapineige
Copy link
Member

I would suggest longer default, especially as it will be applied for all users with no tweak to the config file on the next update (to give them time to react), and to not surprise too much the users.

I would go for 2 months (60 days) for the trashbin (it can be suited for least-active servers), and 3 months (90 days) for versioning for safeguarding.

I made a PR to add doc about this. The doc will have to be updated if the default yunohost parameter is changed.

Nice 👍
An admin doc message should be displayed after the upgrade, with instructions about how to change the parameters imho.
If someone have time to contribute to it, even a config panel option so there would be no manual editing of the config file (and future conflicts) and to make it more accessible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants