view->getPath($id) returns strange path for delete files

[nickvergessen]

If a file is deleted and moved to the trashbin, getPath($id) returns _trashbin/$path.$timestamp.
Looks like we just cut off files no ignoring whether it is files/ or not.

Is this intended? @icewind1991 @PVince81

[PVince81]

Unlikely to be intended.

We should probably limit getPath() to return files under "files" or from ext storages.

[nickvergessen]

Okay, maybe it's a question of setting up. When you use chroot('/user/files') the problem exists. Using chroot('/user/files/') does not have the problem. But then you need to have all paths without leading slash.

So I think it's still worth fixing

[PVince81]

This also affects federated shares where the source was moved to trash.

[PVince81]

The view's root is "/root/files" and it calls "getRelativePath('/root/files_trashbin/files/tetsac.d1440425391')". This sounds like the known getRelativePath issues: #16479

[PVince81]

Mega-dirty-quickfix:

    $ownerView->chroot($ownerView->getRoot() . '/');

[PVince81]

Also happens in setupFromToken for public shares... I guess it's time to revive #16479

[PVince81]

In my case it looks like #16479 fixes the issue.
Can you try it too ?

[ghost]

@PVince81 @nickvergessen pick up this issue again?

[nickvergessen]

Well it is fixed by #16479 which is waiting for merge iirc