Skip to content

Conversation

@artonge
Copy link
Contributor

@artonge artonge commented Apr 7, 2025

No description provided.

@artonge artonge force-pushed the artonge/fix/trashbin_retention_d1 branch from 6da12de to dc88165 Compare April 7, 2025 08:49
@artonge artonge requested review from come-nc and yemkareems April 8, 2025 07:54
Copy link
Contributor

@come-nc come-nc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would keep the parenthesis or some form of it, to make it clear that deletion may never happen.

Also, quota can be infinite, in which case it will still delete files when storage is full I think?

@artonge
Copy link
Contributor Author

artonge commented Apr 23, 2025

I would keep the parenthesis or some form of it, to make it clear that deletion may never happen.

I think deletion will always happen if the quota is reached.

Also, quota can be infinite, in which case it will still delete files when storage is full I think?

I am not sure, at least I haven't found any bit of logic for that. I think expiration is only based on user quota.

@come-nc
Copy link
Contributor

come-nc commented Apr 24, 2025

I would keep the parenthesis or some form of it, to make it clear that deletion may never happen.

I think deletion will always happen if the quota is reached.

But quota may never be reached. That is what is clearer with the previous parenthesis content.

Also, quota can be infinite, in which case it will still delete files when storage is full I think?

I am not sure, at least I haven't found any bit of logic for that. I think expiration is only based on user quota.

Hum, I don’t know, I know that shown quota is storage space when no quota is set, but I do not know for expiration. It should be fixed if it’s not currently the case though, as there is no reason to not expire or full storage if we do it for full quota?

@artonge artonge force-pushed the artonge/fix/trashbin_retention_d1 branch from dc88165 to 2cca00d Compare October 17, 2025 15:32
Signed-off-by: Louis Chemineau <[email protected]>
Signed-off-by: Louis Chmn <[email protected]>
@artonge artonge force-pushed the artonge/fix/trashbin_retention_d1 branch from 2cca00d to 0472da8 Compare October 17, 2025 15:33
@artonge artonge marked this pull request as draft October 17, 2025 15:37
@artonge
Copy link
Contributor Author

artonge commented Oct 17, 2025

Changes need to be done in server: nextcloud/server#55834

@artonge artonge closed this Oct 17, 2025
@tcitworld
Copy link
Member

Hum, I don’t know, I know that shown quota is storage space when no quota is set, but I do not know for expiration. It should be fixed if it’s not currently the case though, as there is no reason to not expire or full storage if we do it for full quota?

@artonge @come-nc mind giving a look at nextcloud/server#55742 which should address that?

@artonge
Copy link
Contributor Author

artonge commented Oct 21, 2025

mind giving a look at nextcloud/server#55742 which should address that?

@tcitworld I don't get your changes in that linnked PR.

I understand that deleteExpiredFiles was purposefully not based on the quota to only expire files that are older than the max retention time. So it feels like a duplicate to change it like that, as we then call deleteFiles which will do the same, no?

However, it seems to make sense to replace the call to Trashbin::deleteExpiredFiles($dirContent, $uid); with Trashbin::expire($uid); in order to actually remove trashed files if the quota is reached.

Can you clarify if I understand your changes properly? And you think that they still make sense? Also, would definitely appreciate your feedback on the doc update :).

@tcitworld
Copy link
Member

I understand that deleteExpiredFiles was purposefully not based on the quota to only expire files that are older than the max retention time. So it feels like a duplicate to change it like that, as we then call deleteFiles which will do the same, no?

Indeed, thanks for your vigilance! I simply completely missed that deleteFiles was indeed calling isExpired properly (bad navigation in my IDE because of lack of proper typing). 🙈

I'll revert 195d347240ed370d2ddcfc8f985c35bebe83ab8c and keep cea23fb53d58e5173f745adf61f22345651cca1f.

However, my initial issue still stands. If there's no quota set and little or no available space left on disk then the trashbin is not cleaned.
We can at least change $availableSpace < 0 to $availableSpace <= 0 in deleteFiles so that when the disk is really full it triggers a cleanup (because if no user quota is set $availableSpace will always be 0 or above), but I wonder if I should just remove the if ($softQuota) { condition in calculateFreeSpace so that it applies as well to the case with no space left on disk but not user quota set.

Possibly there's a need for a allow_trashbin_emptying_when_disk_full setting to make sure.

This whole thing needs a huge refactoring 😭

@artonge
Copy link
Contributor Author

artonge commented Oct 21, 2025

I'll revert 195d347240ed370d2ddcfc8f985c35bebe83ab8c and keep cea23fb53d58e5173f745adf61f22345651cca1f.

Make sense, thanks!

We can at least change $availableSpace < 0 to $availableSpace <= 0 in deleteFiles

Make sense too!

but I wonder if I should just remove the if ($softQuota) { condition in calculateFreeSpace so that it applies as well to the case with no space left on disk but not user quota set.

I don't think so. If there is no quota, then we don't need to compute the soft quota because we have "unlimited" space, no?

This whole thing needs a huge refactoring 😭

Yeah, the whole code is really hard to understand 🫂

@tcitworld
Copy link
Member

If there is no quota, then we don't need to compute the soft quota because we have "unlimited" space, no?

I mean when we actually don't have unlimited space, when Filesystem::free_space('/') returns a low value ("hard quota"). So that we make sure the disk isn't filled just because big trashed files of a quota-less user are not expired.

@artonge
Copy link
Contributor Author

artonge commented Oct 21, 2025

I mean when we actually don't have unlimited space, when Filesystem::free_space('/') returns a low value ("hard quota"). So that we make sure the disk isn't filled just because big trashed files of a quota-less user are not expired.

That would allow Nextcloud to free some space before actually having a filled disk? In other words, if a user stores more trashed files than 50% of the free disk space, then some files will be trashed for good.

Not sure, I think for now we should stick to the documented behaviour instead of preemptively deleting files.

  1. This will only push back the issue for some time.
  2. If a disk is full, I think it is not Nextcloud business, the sysadmin should be alerted in some way.

tcitworld added a commit to nextcloud/server that referenced this pull request Oct 22, 2025
tcitworld added a commit to nextcloud/server that referenced this pull request Oct 23, 2025
artonge pushed a commit to nextcloud/server that referenced this pull request Oct 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants