public links no longer work after restore of shared folder

[karlitschek]

The scenario is this:

someone in an organisation shares folder with a group of people. Then people in this group create public links to files in this folder. If someone deletes this shared folder and restores it then the public links don´t work any more.

@schiesbn What do you think?

@msrex

[schiessle]

that's the expected behavior with the current implementation of the trash bin. The trash bin doesn't remember shares. If a folder gets deleted and restored later on all shares fol the folder and it's content will be gone

[msrex]

Maybe this is the expected behaviour, but it is unusable and needs to be
fixed. The current behaviour makes the use case "ownCloud is the
externally linked file store in other web services) inpractical.

[schiessle]

of course we could also store the share relations. But we should keep in mind that this will be a quite expensive operation. If we delete a folder we would need to go recursively through the folder and collect each share for each file/directory. This could already take quite some time if you think about a large directory.
If a user restores the folder again we couldn't simply write the stored share information back to the sharing table because in the meantime people could have created files/directories with the same name. So we would need to check for every recipient if the share target is still valid and adapt it if needed. This would also mean that a directory/file could appear on a complete different place after it was restored for a user. Also the file-id would be different after the files are restored. We would not only need to update the file-id for the direct shares but also calculate the parents for the re-shares again.

Until now we agreed that storing share information in the trash bin is out of scope. Of course we can reconsider it. But we should keep in mind that this would add quite some complexity and we shouldn't forget the possible impact on the performance.

In my opinion there is one solution which would make it possible to consider keeping all the share information: Instead of moving files to a separate trash bin directory we could keep the files where they are, just rename them from "directory" to "directory.d" to make it possible to upload new files with the name of already deleted files and flag them as deleted in the file cache. This way we could also keep the share table as it is without the need of moving something around. If the user deletes a file we would keep all information and just hide it. If the file gets restored it just becomes visible again. This would be a great performance improvement, also compared to the current trash bin and would make it possible to add additional features like keeping the shares. Only drawback: In case the user also access the storage without ownCloud, e.g. if you think about a samba drive, then he would see all the "*.d" files until they get deleted permanently or restored.

[DeepDiver1975]

Full ack to the comments on performance and complexity.

Regarding *.d - please no further path magic Kung-Fu - *.part files special handling is already enough

[schiessle]

Regarding *.d - please no further path magic Kung-Fu - *.part files special handling is already enough

Just to complete the picture. If we would decide to go this path I wouldn't add additional special handling for *.d files. The *.d renaming would be just to free the filename. At the same time I would introduce a "hide" flag on file cache level as we already discussed in the past. Then both "part"-files and deleted files would just be hidden by a flag and made visible again if the "part"-file was uploaded completely or the deleted file was restores. So it wouldn't necessarily add additional magic. The main problem for this solution is probably that deleted files would still be available if people access the storage without ownCloud. At least this was the main reasons why we decided against it in the past.

[karlitschek]

Whatever we decide to do here. We first have to finish the implementation of the planet ownCloud 7 features and then look into this.

[PVince81]

As for OC 7 only the owner can delete the shared folder, but this would still be an issue as share information will be lost.

[PVince81]

Closing in favor of #10158