Meta data lost when recipient restores a file

[nickvergessen]

Steps to reproduce

1. Create a file in a folder
2. Comment and tag that file
3. Share the folder
4. As recipient delete the file
5. As recipient restore the file

Expected behaviour

Comments and tags should still be there

Actual behaviour

Comments and tags are missing, because the file ID changes, when the item is restored by a recipient instead of the owner

Server configuration

ownCloud version: 9.0 beta 2

List of activated apps:

• Comments
• Tags
• Trashbin
• Sharing

@PVince81 @schiesbn

[nickvergessen]

Possible Solution

1. We should try to restore the file of the owner instead of the recipient, when the item is still shared and the owner didn't delete the file and ...

Since this solution is rather complicated with the conditions that can happen (unshare of parent, delete, etc.) it might be needed to copy meta data on copy?

For 9.0 we should at least consider to copy the tags, to make sure the work of the autotagging app is still as desired.

cc @DeepDiver1975

[DeepDiver1975]

deleting a share file means unshare - so restore should then be a 'simple' un-unshare.

what am I missing?

[PVince81]

@DeepDiver1975 this is not about single file shares.

Share a folder and have the recipient delete a file inside that shared folder.
The default logic will move the file to trash for both the owner and recipient.
Only the owner keeps the fileid.

[MorrisJobke]

Only the owner keeps the fileid.

...and the recipient gets a copy of those files to be able to restore them. (but this will result in a new fileid)

[DeepDiver1975]

Share that file

so step 3 is wrong - should be - share the folder containing the file

[DeepDiver1975]

The default logic will move the file to trash for both the owner and recipient.

so this duplication of data requires duplication of tags and comments as well ... bääh

[PVince81]

bääh

you got it

[nickvergessen]

so step 3 is wrong - should be - share the folder containing the file

Right, sorry fixed the steps

[DeepDiver1975]

Right, sorry fixed the steps

np - thx

[DeepDiver1975]

For 9.0 we should at least consider to copy the tags, to make sure the work of the autotagging app is still as desired.

I tend to agree on that ... what about creating a copy of a file? Does this cause copy of tags and comments?

[nickvergessen]

what about creating a copy of a file? Does this cause copy of tags and comments?

Currently it does not

[DeepDiver1975]

Currently it does not

we should consider this ... any file can be copied via webdav

[nickvergessen]

the problem is, when you copy a folder, you need to recursivly do all that...

[DeepDiver1975]

the problem is, when you copy a folder, you need to recursivly do all that...

true :puke:

[PVince81]

No topic for 9.1, this is a conceptual issue in the trashbin and might need a redesign

[PVince81]

Note, to clarify the title: the metadata is already lost at the time we create a copy of the files for the recipients. Only the owner has access to the old metadata.

So far a proposal was to have a special link so that when the recipient triggers a restore of the file, it will actually trigger a restore from the owner's perspective. This is fine for this one scenario.

However there will likely be another scenario for #24053 when moving out a file out of a share would also create a copy in the owner's trashbin. In this case we can't keep a link in the same way. Maybe we need to copy the metadata.

But looking at copying metadata would mean copying all the following:

• system tags
• favorite info (might be tricky because it's specific for every user)
• comments
• activities ?
• link share info ? (if both owner and recipient restore the file then the link share would exist twice ?)

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[felixboehm]

also direct links get lost

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[PVince81]

moving to triage.

this would need a redesign of trashbin and/or the storage architecture to allow for linking files (symlinks or virtual files) to allow multiple trashbins to contain the same file entries with the same file id

estimate for coming up with multiple possible concepts: 1-2md.
implementation estimate unknown but likely more than 5md

[stale]

This issue has been automatically closed.