Thumbnails not regenerated when reverting to an earlier version of a file

[jnfrmarks]

Steps to reproduce

1. Make sure the Versions app is enabled
2. Create a new document (click on "new"->text file from the "files" view)
3. Enter some basic text; save; close
4. Validate that the thumbnail next to the file is accurate
5. Edit the file a second time
6. Validate that the thumbnail changed as expected.
7. Highlight the file, select "versions", select previous version
8. The thumbnail did not revert

I see this with both FF and chrome. I cleared the cache to ensure that this isn't a caching issue.

Expected behaviour

The thumbnail should revert too

Actual behaviour

The thumbnail reflects the earlier version

Server configuration

ownCloud version: (see ownCloud admin page)

ownCloud 7.0.1 (daily) Build:2014-08-20T03:18:51+00:00

[karlitschek]

@schiesbn @georgehrke

[georgehrke]

Looks like a missing hook

[MTRichards]

Would be good to regenerat thumbnails when a file is reverted, and also when a new file is uploaded with the same name. See #10822
Related?

[georgehrke]

@MTRichards

Just like in #10521:
#10822 is related to the gallery app. This is an bug in the preview system itself

[MTRichards]

Thanks @georgehrke

[georgehrke]

Ok, so I digged into this problem and it seems like some logic error / missing hook in the versions app.
When you create a new file it gets an Id.
Let's say the file is called test.txt and the Id is 1.
After editing test.txt:

• the file is still called test.txt
• the id of username/files/test.txt is still 1
• a copy of the old version of username/files/test.txt was created
  • it's called username/files_versions/test.txt.{revisionTimeStamp}
  • its id is 2
• a write hook is emitted -> the old preview is deleted

When reverting to an old version:

• the file is still called test.txt
• the id of username/files/test.txt is still 1
• a copy of the new version (that's being overwritten by the old version) was created
  • it's called username/files_versions/test.txt.{revisionTimeStamp}
  • its id is 3
• no write hook is emitted -> the old preview is not deleted
  • Neither an \OCP\Versions hook nor some OC_Filesystem delete/write hooks

When grepping over the files_versions code I noticed that there are actually no hooks executed when reverting to an old file. There are only hooks being emitted when the file is deleted because a user's disk space almost full.

@schiesbn I am probably missing something here. How are other apps supposed to know when a file was reverted to an old version?

[georgehrke]

ping @schiesbn

[georgehrke]

ping @schiesbn

[georgehrke]

ping @schiesbn

[georgehrke]

@schiesbn please comment on #10559 (comment)

[oparoz]

When reverting to an old version: no write hook is emitted -> the old preview is not deleted

@schiesbn @PVince81 Has the missing hook been added to OC8?

[schiessle]

@georgehrke I think you are right. We didn't noticed this until now because no other app had to listen to a revert event.

OC\Filesystem doesn't trigger a hook on revert because to operation happens outside of data/<user>/files. This means that we most likely need a versions related hook. I would suggest to just emit a hook here https://github.com/owncloud/core/blob/master/apps/files_versions/lib/storage.php#L273 with all the information you need.

This could be also interesting for the activity app cc @nickvergessen

[schiessle]

BTW, sorry that it took me so long to response to this issue. Feel free to ping me on IRC, Jabber or E-Mail the next time you need a answer and I don't reply in time to a github issue.

[nickvergessen]

Well activity app is unaffected, since it always displayes the current preview.

[SergioBertolinSG]

Please note, not only the thumbnail but the big previewed picture.

[SergioBertolinSG]

Fixed in last master.