-
Notifications
You must be signed in to change notification settings - Fork 85
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
sftpgo s3afero compatibility #60
Comments
Hey @piedshag, thanks a lot for starting the discussion. I'm not at all familiar with the Sftpgo codebase so in many ways I can probably not comment very well. The only "concern" I would see: what happens if someone adds 0 byte files for testing purposes and thus would now get directories instead. |
I confess I haven't thought this through fully, but my first reaction is to ask if this could be done with a wrapper/middleware backend? That way, any backend can be put behind it, and users of the API can choose whether a backend is wrapped with this support? |
Hey @johannesboyne @shabbyrobe, thanks for getting back to me.
Thanks for raising that, I have changed my fork so that it checks both the file is 0 bytes and the content-type is "application/x-directory". There shouldn't be any accidental directories this way.
I think the changes would bring gofakes3 more in line with the s3 API and wouldn't conflict with the current uses. I have tested sftpgo out with the other backends and it seems that we would have to make a couple of changes like this to make them compatible as well. The changes are small and I think they would be a good default feature to boost gofakes3 compatibility. |
There is a place in the repo where I was testing some assumptions a while back, I think it would be worth adding something to it that proves this assumption first: https://github.com/johannesboyne/gofakes3/tree/master/internal/s3assumer |
I will take a further look during the easter break! Thank you for your patience ;-) |
I am happy to push this further and clearly see the why. A wrapper would be cool even though looking at your comment @piedshag from 16 days ago, it is considerably low effort to make the changes directly in the backend though. Have you already moved forward with this in your fork? |
Hi @johannesboyne, thanks for getting back to me. I'm just finalising some changes with my fork but I will submit a PR when its ready. |
Hello,
Sftpgo supports using a s3 backend but I've come across some compatibility issues with gofakes3 when using the s3afero backend.
I've managed to resolve the following issues through a couple of changes:
To create a directory, sftpgo will write a 0 byte blob with content type
application/x-directory
and keydirectory_name/
. This is the way that AWS recommends creating folders but it doesn't work with a fs backend. To counter this, if we notice that the file being written is 0 bytes we will delete it and create a directory in it's place.The other issues are to do with how sftpgo interprets folders. If it is changing directory it will first run a head lookup on the key without the trailing "/", if that fails, it will check to see if it is a folder, so we want to return
key missing
if it checks on a directory without the trailing "/". It checks differently when you're running a recursive get, it will first list out all the folders then mark directories if they have the trailing "/".I've made the changes here, it adds functionality for mkdir, changing directories, recursive get and recursive put. I've only made them for the multibucket option, but they could be extended to the other options.
I'm interested to hear your thoughts on potentially getting this merged into master. Are these changes you'd be happy to merge and if so, would you prefer I open a PR to work on getting these changes merged?
The text was updated successfully, but these errors were encountered: