Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move file drop collision detection to storage provider #8358

Open
butonic opened this issue Feb 2, 2024 · 0 comments
Open

Move file drop collision detection to storage provider #8358

butonic opened this issue Feb 2, 2024 · 0 comments
Labels

Comments

@butonic
Copy link
Member

butonic commented Feb 2, 2024

As a follow up of #8291 which was implemented with cs3org/reva#4491 we should move the filename collision detection and renaming to the CS3 storage provider. Currently, only uploads via ocdav will rename files. Direct CS3 and dataprovider calls would still overwrite the file.

In order to solve this the logic should bove behind the CS3 api. Putting it into storage drivers would mein they have to reimplement it every time. So the correct place IMO is the storage provider.

However, I also think the storage provider should do far more than what it currently does. We should move a lot of business logic from decomposedfs to the storage provider. By extracting different storage aspects like Tree, Node, Lookup and others from decomposedfs we can make them reusable. Every storage first has to look up the Node for a given reference and then has to check if the user has the correct permissions. These two steps should be implemented like middlewares. Then the storage drivers will become less repetitive. Currently, every Storage interface implementation starts with some wrap/unwrap/lookup magic and then a permission check.

Furthermore, upstream CS3 extracted a space manager from the storageprovider api, which also affects what storage drivers need to implement.

So, a few things need to settle down before we can move the logic to a better place. Until then this issue needs to be kept open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant