Open hmalessa opened 6 years ago
GitMate.io thinks the contributors most likely able to help are @ownclouders, and @PVince81.
Possibly related issues are https://github.com/owncloud/core/issues/22327 (Allow multiple link shares), https://github.com/owncloud/core/issues/7813 ([FEATURE REQUEST] Share link with multiple users has different link), https://github.com/owncloud/core/issues/11097 (Shared links expire with no expiry date set), https://github.com/owncloud/core/issues/15022 (Share link hangs), and https://github.com/owncloud/core/pull/31129 (Add missing public link share dialog features).
From what I see in the code the deletion should only affect shares that are actually expired: https://github.com/owncloud/core/blob/v10.0.9/lib/private/Share20/Manager.php#L1129
There is a loop that checks for each share.
@hmalessa how far apart were the expiration dates ? Is this reproducible consistently ? Are maybe time zones involved where maybe you believed that the second link was still valid but a time zone difference might have deleted it early ? (see https://github.com/owncloud/core/issues/8363 for the timezone issue)
I've set up a test case on my server (10.0.9) and will see whether the observed problem happens there as well.
I had set a link to expire today and another next week. Today I opened the share panel for the folder in question and I can see that today's link did disappear, but the one from next week is still there.
So no problem observed so far...
@hmalessa when you say "wait until expiration date of first link" there must be a step after that: are you opening the expired link ? or are you opening the share panel as I did ?
because the action you did after that is important as the expiry logic is triggered only the next time the link is accessed or listed
@ownclouders, and @PVince81
Adding to this old thread. We also expirenced this behaviour today. We have directories with multiple public shares, one expiring the day of the issue (old link) and another expiring two weeks into the future (new link). When the old link expired, it also removed the new link we uploaded that day.
New to GitHub so any information required please let me know and I'll provide it.
Showing share activity, note two shares uploaded and only one expired:
Showing no public links after first one expired. Should be at least one link as there are not two expire events:
@dpakach we did some tests for link expiry recently. IMO we should now be able to add a test scenario where there are 2 public link shares of a resource. Then we put the expiry of one of them into the past, and access that "past-expired" link share. That should cause the "past-expired" link share to disappear. But the other link share that expires in the future should still exist.
Such a test scenario should be able to demonstrate this problem - and then someone can fix it.
I added this to the QA Test Automation project so that we can demonstrate the issue.
We added a test scenario in #39100 and that passes. I tried a few permutations of that locally, and could not find a sequence that failed. @SwikritiT tried locally to make public links with different expiry dates, and let one expire "naturally" overnight. And still we don't see the problem.
The other place that could be a problem is https://github.com/owncloud/core/blob/master/apps/files_sharing/lib/ExpireSharesJob.php - maybe if that runs, and finds a public link share that has expired, that it accidentally removes all the public link shares of the resource. But looking at the code, it explicitly queries the database only for shares with expiry before "today". And it loops through that list deleting the shares.
Before PR #38775 if there was a share that expired yesterday (1), and a share that expires today (2), and a share that expires tomorrow (3), then both (1) and (2) would have been deleted. After that PR (i.e. in 10.8.0 release) only (1) gets deleted.
Please try with 10.8.0 and let us know if you can still reproduce the problem.