Link Size field

Help
1

It seems that an object’s links’ “Size” field is taken at face value during object put. This directly impacts the cumulative size of an object reported by object stat. I am wondering what the purpose of the “Size” field is if it goes entirely unchecked? I’ve started to dig into the go implementations of the various libraries and have so far not found any control flow directly influenced by the “Size” property, but I might have missed something. If the “Size” field plays no role for internal control flow, and goes unchecked, could it be either removed or generalized to some key value meta field on Links?

2

We use this field to implement efficient seeking in go-unixfs - https://github.com/ipfs/go-unixfs/blob/master/io/pbdagreader.go. You can access this seek in a few ways:

  • By specifying Range header with gateway requests
  • Using --offset flag in ipfs cat
  • Using file.Seek() on files returned by CoreAPI.Unixfs().Get() - this currently requires using go-ipfs node directly from Go code, which is hacky, http backed implementation should come soon-ish (coming months) - watch https://github.com/ipfs/go-ipfs/issues/4498 for updates
3

Thank you. What is your take on the size field going completely unchecked for object put though? Maybe it should be derived internally? For example, if I create an object with some links, i should be able to look up those links and get the size of the objects based on the links, right? I assume that would be terribly inefficient (perhaps even impossible?). Since you mentioned it’s used in unixfs, maybe the links format should be extensible by whatever subsystem is using them?