[windows] util.addFromFs goes up almost to the root directory

[Mithgol]

I've just tried util.addFromFs (on a directory of Bootstrap) and received the following array:

It stores in IPFS the bootstrap directory and its contents, which is good, but then it goes up to three levels of parent directories (almost to the root), which is not so good because:

• it's somewhat scary (resembling a permanent data leak) even though it does not really store in IPFS anything from those parent directories except the name of the child it came from,

• it's not convenient (because it means I cannot just grab the last element of the returned array and assume that's bootstrap).

Some technical details:   JS IPFS API v11.0.1, Node.js v6.8.1 (64-bit), Windows 7 Professional Service Pack 1 (64-bit).

[Mithgol]

Thanks!

Fixed in v12.1.3 and newer, correct?

[daviddias]

Correct :) Thanks to the awesome @JeffDownie :D

[Mithgol]

The problem seems to persist in IPFS API v12.1.4, this issue should be reopened.

Here's a screenshot to demonstrate the problem:

In its topmost lines npm reports that IPFS API version 12.1.4 is installed (except the dependency node-webcrypto-ossl@1.0.16 which is optional).

In its bottom lines the recursive .addFromFs of the directory 'bootstrap' proceeds to add its three parents.

[thisconnect]

Found this as I am having same effect "goes up to the root" when using api.add and api.files.add (wrongly) on Mac OS X

Passing an array of objects each with an absolute path (without a content property) does bubble up to root.

macos 10.12.5
ipfs-api 14.0.4
go-ipfs (from source) 0.4.10

Could not reproduce the same issue with util.addFromFs on MacOS

const ipfsAPI = require('ipfs-api')

const api = ipfsAPI('/ip4/127.0.0.1/tcp/5001')

api.files.add([
  { 
    path: '/Users/name/Desktop/file.png'
    // should have content property here
  }
])
.then(console.log)
.catch(console.error)

Note: it seems to not matter if the file exists or not.

[daviddias]

With ipfs/js-ipfsd-ctl#164 (thanks @thisconnect) I would be down to add appveyor CI to this module since we have so many users of go-ipfs and js-ipfs-api in Windows.

Thoughts?

[richardschneider]

Looks like PR #624 will fix this problem.

api.util.addFromFs('examples/name-api', { recursive: true }, (err, res) => console.log(res) )
undefined
> [ { path: 'name-api/index.html',
    hash: 'QmaXbimrrTpFL7SSVxdNABvFQTkP427LJ21dhqEqTS6MoP',
    size: 1692 },
  { path: 'name-api/index.js',
    hash: 'QmXjJGe3kzhKo4cXpHWZ79pNfdvux1Q75WxBkKmyzDEdEq',
    size: 3218 },
  { path: 'name-api/package-lock.json',
    hash: 'QmQLT6VSzg7uKJZ4Vkw7D8rPdaVVgTNhsS3J23EK1p849Y',
    size: 68988 },
  { path: 'name-api/package.json',
    hash: 'QmdnnbYiZA4JA7Fq6Grj5yzm9bsLLNskWS4VhNBZe8aHzp',
    size: 388 },
  { path: 'name-api/README.md',
    hash: 'QmQmomRe6rZpKYZPKnZ29MGH3eh8abkxV6M1vuNPfoyvJX',
    size: 358 },
  { path: 'name-api',
    hash: 'QmTroiByZLBF5xo785SeDZHQcZ55dwatjQVmzsEnFaNbPb',
    size: 74920 } ]

>

[daviddias]

Merged and released as v15.1.0. Thank you @richardschneider ! :D