I'm aware of the request for symlink or redirect support (this is the 3rd time you're asking). Seems

I'm aware of the request for symlink or redirect support (this is the 3rd time you're asking). Seems unlikely we'll implement it in any short term. There are several challenges.

  1. That operation doesn't exist at all in S3 which means what does the shape of the REST query look like in a way that remains future-proofed against conflicting with future changes AWS makes?
  2. This operation doesn't exist at all which means how do you make it accessible from tooling?
  3. What is the expectation around behavior if the original file is deleted?
  4. It complicates the metadata layer a bit.
It's probably tractable by hanging it off of
CopyObject
as a custom copy directive (we have
REPLACE
so probably SYMLINK might work there). That solves 1 and 2 but makes 3 weird since after issuing a
CopyObject
to create object2/test2.txt --> object1/test.txt, DeleteObject object1/test.txt, the copy "doesn't exist" and is dangling metadata that you'd be billed for that's difficult to cleanup (you'd have to basically try to access that object or encounter it in a list). What happens if you now put a new object1/test.txt
  • is the symlink expected to work? The solution here is probably that such a redirect shows up in ListObject but always returns a 404 on a GET (but does it respond to a HEAD request? maybe only if there's an option that says "don't resolve symlinks"?)
4 pops up because what happens if you:
  1. PutObject object1/test.txt
  2. CopyObject
    object2/test2.txt --> object1/test.txt
  3. CopyObject
    object1/test.txt --> object2/test2.txt
    This isn't even getting into the concept of making cross-bucket symlinks.
The hand wavy concept is easy to comprehend but making sure all the corner cases have defined semantics that don't surprise you in behavior, less so. Object storage systems look like filesystems but they're not.
Was this page helpful?