- Author: Xuanwo github@xuanwo.io
- Start Date: 2021-06-08
- RFC PR: beyondstorage/specs#86
- Tracking Issue: beyondstorage/go-storage#611
We have ModeLink for Object which means this Object is a link which targets to another Object. A link object could be returned in Stat or List. But there is no way to create a link object.
As discussed in Link / Symlink support, link related support is very different in different services:
- fs: Native support for hardlink and symlink
- oss: Native Symlink API
- s3: No native support, x-amz-website-redirect-location can redirect pages but only works for website, see https://stackoverflow.com/questions/35042316/amazon-s3-multiple-keys-to-one-object#comment57863171_35043462
I propose to add a new CreateLink operation:
type Linker interface {
CreateLink(path, target string, pairs ...Pair) (o *Object, err error)
}pathis the path of link object.pathCOULD be relative or absolute path
targetis the target path of this link object.targetCOULD be relative or absolute path
As described in GSP-87, CreateLink could also be virtual functions.
- Service without native support COULD implement
virtual_linkfeature. - Users SHOULD enable this feature by themselves.
We will only support Symlink and simplify it to Link instead.
A service doesn't have native support for Link, so we implement one for it. After few months, the service supports it.
How to handle old-style objects? How to avoid data corruption
The feature gates will be kept until next major release.
- If user enabled
virtual_link, service SHOULD run compatible mode: create link via native methods, but allow read link from old-style link object. - If user didn't enable
virtual_link, service will run in native as other services.
Finally, those compatible code will be removed in next major release, and virtual_link feature will be removed.
This proposal is compatible.
- Add new operations and new features in specs
- Implement integration test
- Implement Linker for services