fix: cache invalidation issues

[solracsf]

Problem

Context: nextcloud/server#57973 and nextcloud/server#49126

Files shared with teams were not syncing properly on desktop clients. When files were added, modified, or deleted in team-shared directories, the ETag was correctly updated in the database but clients received stale ETags from the distributed cache, preventing synchronization.

Root causes:

1. The clearCache() method in ShareWrapperService was broken - it used singleId as the cache key but actual keys follow the format singleId#nodeId#probeSum, causing cache invalidation to silently fail
2. No event listeners existed to detect file modifications and trigger cache invalidation - cache was only cleared when shares or memberships changed, never when files themselves were modified

Fix nextcloud/server#57973

Note

While testing, please enable debug mode to print debug messages.

[Ornanovitch]

/backport to stable33

[Ornanovitch]

/backport to stable32

[Ornanovitch]

/backport to stable31

[CarlSchwan]

Make sense to me

[cristianscheid]

@solracsf I was investigating this issue as well, and what you did makes a lot of sense to me.

Unfortunately, when testing the fixCacheInvalidation branch with server on master branch, I get this error when trying to rename a file:

Toast (feedback):
Could not rename "<filename>"

Request:

MOVE
http://nextcloud.local/remote.php/dav/files/admin/new/<old_name_before_rename>
500 Internal Server Error

Response:

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Error</s:exception>
  <s:message>Call to undefined method OCP\Files\Events\Node\NodeRenamedEvent::getNode()</s:message>
</d:error>

Does this happen for you as well?

Other than that, adding/removing files from within a shared folder correctly updated the folder etag in my tests. I verified this using curl as suggested in issue #57973, and running the command before and after the file operation confirmed the etag updated and matched the value in the oc_filecache table:

curl -X PROPFIND -u "{user}:{pass}" \
        -H "Depth: 0" \
        "https://{server}/remote.php/dav/files/{user}/{team_shared_folder}/" \
        --data '<?xml version="1.0"?><d:propfind xmlns:d="DAV:"><d:prop><d:getetag/></d:prop></d:propfind>'

[solracsf]

@cristianscheid try latest commit a7baf35 on your patched instance

Tested locally, rename works as expected.

[cristianscheid]

@cristianscheid try latest commit a7baf35 on your patched instance

Tested locally, rename works as expected.

@solracsf Thanks for the adjustment! I tested locally again using curl before and after renaming a file, and it worked as expected.

[solracsf]

Thanks for testing.
Let's wait for reviews from other maintainers 👍🏻

[CarlSchwan]

btw the red psalm ci is fixed by #2356 in case anyone wants to review ;)

[provokateurin]

@solracsf please rebase

[solracsf]

@provokateurin rebased and all green 🟢

[solracsf]

/backport 1cdb52d to stable33

[solracsf]

/backport 1cdb52d to stable32

[solracsf]

/backport 1cdb52d to stable31