Previews-thumbnails get out-of-sync when edited by sharer and sharee

phil-davis commented 6 years ago

Steps to reproduce

as "user1" create folder "test" and in it put "testfile.txt" with content "owner" - thumbnail says "owner" - good
share folder "test" with "user2"
as "user2", edit "testfile.txt" and put content "user2 text"

thumbnail displayed to "user2" is not updated, it still says "owner"

login as "user1" - the thumbnail displays "user2 text" - good
login as "user2" again - look at the thumbnail of the file

thumbnail displayed to "user2" is not updated, it still says "owner"

login as "user1" again, edit the file and put content "user1 text" - thumbnail is updated - good
login as "user2" again - look at the thumbnail of the file

thumbnail displayed to "user2" is not updated, it still says "owner"

Expected behaviour

The share receiver "user2" should always see a preview-thumbnail that is in sync with the file content.

Actual behaviour

The share receiver "user2" gets "stuck" with the preview-thumbnail that was generated at the time they first received/looked at the file.

Server configuration

10.0.9RC1 plus PR #31853 (which fixes missing hooks for thumbnail generation in 10.0.9RC1)

10.0.8 as symptoms similar to this, but might be a bit different.

phil-davis commented 6 years ago

Ideally the thumbnail of a file would be stored only once, in the "file system" of the file owner. Just like the file itself is stored only once, in the "file system" of the file owner.

If the share receiver "user2" is able to write back new content to the file owned by "user1" (even when encryption is happening) then "user2" should be able to also write back new content to the thumbnail owned by "user1" - and actually that seems to be happening because "user1" is seeing the correct updated thumbnail.

Maybe all that is needed is to stop writing a "duplicate" thumbnail in user2's file system?