Js-ipfs: ipfs.add() - duplicated paths

[AuHau]

ipfs.add() allows to submit duplicated path as follows:

it.only('duplicated files', async () => {
  const result = await ipfs.add([
    {
      path: 'folder/file',
      content: Buffer.from('hello world')
    },
    {
      path: 'folder/file',
      content: Buffer.from('another hello world')
    }
  ], { wrapWithDirectory: true })

  const content = await ipfs.get(`${result[result.length - 1].hash}/folder/file`)
  // @ts-ignore
  expect(content[0].content.toString()).to.eq('hello world')
})

From the test, I see that only the later object "survives". I assume that this was your design decision. Tbh I think the add() call should fail, because this leads to possible unexpected results. Especially if you "sell" imitation of folder structures where all OS/FS (to my knowledge) does not support duplicates.

What is really weird though is that result of ipfs.add() is

[
  {
    path: 'folder/file',
    hash: 'Qmf412jQZiuVUtdgnB36FXFX7xg5V6KEbSJ4dpQuhkLyfD',
    size: 19
  },
  {
    path: 'folder/file',
    hash: 'QmRpuoAJk9b8mZ4sS5H1RSrojMQVcM4bBk7deJqiWLe9AW',
    size: 27
  },
  {
    path: 'folder',
    hash: 'Qma9HLRA7zr4ZqPC517dtbb1tJaF6i6XSmCHRbkCz4Mu26',
    size: 77
  },
  {
    path: '',
    hash: 'QmUWYb1uEB5tssvqq4PxnPvqtnPftCj3kdqPYqP44QqZqL',
    size: 129
  }
]

So the first duplicated file is actually added, yet it won't be accessible using QmUWYb1uEB5tssvqq4PxnPvqtnPftCj3kdqPYqP44QqZqL/folder/file.

Can you please tell me what is your reasoning behind this? Is it a bug from your perspective? If nothing then this should at least be documented in SPEC, because I have not found any mention about it there.

[achingbrain]

The importer builds the final tree as it goes along, adding directory entries when encountered, though doesn't check to see if they exist before adding them to the current tree. If it did you'd get the error you expect.

I'm not sure why it was implemented like that but it sounds like it should probably be disallowed, if you are providing paths along with the data you want adding to IPFS.

[alanshaw]

Do you see the same result using go-ipfs?

[AuHau]

Yes, so I assume "go tell go", right? 😶

[daviddias]

it means it is a bug on the actual Unixfs design as it doesn't contemplate this case and doesn't give it a recommendation. Suggestion: start by updating the spec at ipfs/specs so that both implementations can follow

[ay2306]

@alanshaw Can I work on this issue?

[achingbrain]

I've opened https://github.com/ipfs/specs/issues/239 so we can get this resolved & added to the spec.