SAFE Drive - OSX

I’m not sure from this if you’ve installed OSXfuse? But indeed you should so we need to add the following to the README.md (from fuse-bindings requirements):

   - if you use Brew, install OSXFuse and brew install pkg-config
   - if you use MacPorts, sudo port install osxfuse +devel

I’ll follow up further later. :slight_smile:

1 Like

I have fixed some things I broke and created a new git branch to us to work on for Mac OSX, so to update your source code please do the following.

I’m not a git expert but have tested this so it should work (famous last words).

In your safenetwork-fuse directory:

  1. git status will list where you are to see if you have changed any files (these will appear in red). If there are any red files, don’t proceed, but give me a listing (or you could move them somewhere else and move them back at the end).

  2. Now type:

git pull
git fetch --all
git checkout dev-macosx
git checkout .

If you do git status now you should see that you are on branch dev-macosx and I can easily switch to the same code as you in case of problems.

After doing the above, change to your safenetworkjs directory and repeat exactly the same steps.

This is just so you are working with code I can easily look at too, and code I think should work ok for listing and reading files on SAFE.

1 Like

in safenetwork-fuse all good I think:

MacBook-Pro-2:safenetwork-fuse Home$ git status

On branch master

Your branch is up to date with 'origin/master'.

Untracked files:

(use "git add <file>..." to include in what will be committed)

.DS_Store

nothing added to commit but untracked files present (use "git add" to track)

MacBook-Pro-2:safenetwork-fuse Home$ git pull

remote: Enumerating objects: 24, done.

remote: Counting objects: 100% (24/24), done.

remote: Compressing objects: 100% (13/13), done.

remote: Total 24 (delta 11), reused 24 (delta 11), pack-reused 0

Unpacking objects: 100% (24/24), done.

From https://github.com/theWebalyst/safenetwork-fuse

 * [new branch] dev-macosx -> origin/dev-macosx

 * [new branch] dev-savefile -> origin/dev-savefile

f9427b9..3e99ab9 development -> origin/development

Already up to date.

MacBook-Pro-2:safenetwork-fuse Home$ git fetch --all

Fetching origin

MacBook-Pro-2:safenetwork-fuse Home$ git checkout dev-macosx

Branch 'dev-macosx' set up to track remote branch 'dev-macosx' from 'origin'.

Switched to a new branch 'dev-macosx'

MacBook-Pro-2:safenetwork-fuse Home$ git checkout

Your branch is up to date with 'origin/dev-macosx'.

MacBook-Pro-2:safenetwork-fuse Home$ git status

On branch dev-macosx

Your branch is up to date with 'origin/dev-macosx'.

Untracked files:

(use "git add <file>..." to include in what will be committed)

.DS_Store

nothing added to commit but untracked files present (use "git add" to track)

In safenetworkjs I get:

modified: package-lock.json

Yep, that looks good.

No need to worry about that (it will have been updated automatically) so in safenetworkjs:

git checkout package-lock.json

Then git status should be clear and you can proceed.

BTW how are you finding this, not regretting it I hope? :slightly_smiling_face:

not regretting at all…happy to finally be able to (maybe?) help the SAFE community somehow…

so the update is, after the above, npm run build proceeds but with the following errors:

MacBook-Pro-2:safenetwork-fuse Home$ npm run build

> safenetwork-fuse@0.1.0 build /Users/Home/safenetworkjs/safenetwork-fuse

> mkdir -p ./dist/prod/node_modules/@maidsafe/safe-node-app/src/native/prod/ && cp -R node_modules/@maidsafe/safe-node-app/src/native/prod/*.* ./dist/prod/node_modules/@maidsafe/safe-node-app/src/native/prod/ && pkg . -t host -o ./dist/prod/mount-safe

> pkg@4.3.4

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/electron-47.node

path-to-executable/electron-47.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/electron-48.node

path-to-executable/electron-48.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/electron-49.node

path-to-executable/electron-49.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/electron-50.node

path-to-executable/electron-50.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/electron-51.node

path-to-executable/electron-51.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/electron-53.node

path-to-executable/electron-53.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/electron-54.node

path-to-executable/electron-54.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/electron-57.node

path-to-executable/electron-57.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/node-46.node

path-to-executable/node-46.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/node-47.node

path-to-executable/node-47.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/node-48.node

path-to-executable/node-48.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/node-51.node

path-to-executable/node-51.node

> Warning Cannot include addon %1 into executable.

The addon must be distributed with executable as %2.

/Users/Home/safenetworkjs/safenetwork-fuse/node_modules/fuse-bindings/prebuilds/linux-x64/node-57.node

path-to-executable/node-57.node

> Warning Failed to make bytecode node8-x64 for file /snapshot/safenetwork-fuse/node_modules/borc/src/decoder.asm.js

and

./dist/prod/mount-safe

returns

pkg/prelude/bootstrap.js:1176
     throw error;
     ^

Error: No native build was found for runtime=node abi=57 platform=darwin arch=x64
   at Function.load.path (/snapshot/safenetwork-fuse/node_modules/node-gyp-build/index.js:31:9)
   at load (/snapshot/safenetwork-fuse/node_modules/node-gyp-build/index.js:13:23)
   at Object.<anonymous> (/snapshot/safenetwork-fuse/node_modules/fuse-bindings/index.js:1:99)
   at Module._compile (pkg/prelude/bootstrap.js:1252:22)
   at Object.Module._extensions..js (module.js:661:10)
   at Module.load (module.js:563:32)
   at tryModuleLoad (module.js:503:12)
   at Function.Module._load (module.js:495:3)
   at Module.require (module.js:594:17)
   at Module.require (pkg/prelude/bootstrap.js:1157:31)

This good, and I’m glad you are sticking with it and yes, you are helping a lot. :slight_smile:

The first bunch of warnings are just warnings. The second shows you have reached the same point as @lukas who is trying to get this built for Windows. Here is his report, which has the same error as you, and see my reply immediately below his post:

If you can make sense of that have a go, though I know it might not be enough. I’m not at my laptop much today though so take a look and let me know where how far you get.

1 Like

Ok wow, after reading @bzee comment in the windows testing post…
I can confirm node bin starts the app SAFE Network FUSE authenticated!

This is great.

If you set a DEBUG variable when you start it will give you useful output to the console. For example:

DEBUG=safe-fuse*,safenetworkjs* node bin.js

You can also try accessing your SAFE storage. I recommend NOT changing directory to your SAFE drive at the moment, but you should be able to use commands like ls ~/SAFE to examine the directories, and to be able to list the content of files with cat <path-to-file>. Just use full paths for everything for the time being.

And if you are adventurous try tree <some-folder-path>. That takes a while but is very nice to watch (eventually).

Let me know if that works. If it does it just leaves packaging outstanding, and you can also recommend updates to the README.md instructions for MacOS of course.

If you hit any bugs and want to investigate you can try to make sense of the console output, or easier, try the debugger (see the README.md for instructions).

1 Like

A quick test last night with ls ~/SAFE didn’t work, so I’ll try with debug tonight (aussie time) and report back

1 Like

Hi there, the above returns:

**safenetworkjs:web** SafenetworkApi() +0ms

**safenetworkjs:web** SafenetworkApi.initialise() +2ms

**safe-fuse:bin** try safeJsApi.safeApi.bootstrap()... +0ms

**safenetworkjs:cli** __dirname: /Users/Home/safenetwork-fuse/node_modules/safenetworkjs/src +0ms

**safenetworkjs:cli** 

**safenetworkjs:cli** Safe.bootstrap()

**safenetworkjs:cli** with appInfo: {"id":"safenetwork-fuse","name":"SAFE Network FUSE","vendor":"theWebalyst"} argv: {"_":[],"version":false,"help":false,"$0":"bin.js"} +0ms

**safenetworkjs:cli** getLibPath() returning: /Users/Home/safenetwork-fuse/node_modules/@maidsafe/safe-node-app/src/native +1ms

**safenetworkjs:cli** call Safe.initializeApp()... +0ms

**safenetworkjs:cli** call app.auth.genAuthUri()... +49ms

**safenetworkjs:cli** bootstrap.authorise() with appInfo: {"id":"safenetwork-fuse","name":"SAFE Network FUSE","vendor":"theWebalyst","customExecPath":["/usr/local/bin/node","/Users/Home/safenetwork-fuse/bin.js","--pid","59181","--uri"]}appContainers: {"_public":["Read","Insert","Update","Delete"],"_publicNames":["Read","Insert","Update","Delete"]} +16ms

**safenetworkjs:cli** wait a mo +39ms

**safenetworkjs:cli** ipcReceive(59181) +0ms

**safenetworkjs:cli** ipcReceive(59181) +0ms

Server path not specified, so defaulting to ipc.config.socketRoot + ipc.config.appspace + ipc.config.id /tmp/app.59181

starting server on /tmp/app.59181 

starting TLS server false

starting server as Unix || Windows Socket

but the drive doesn’t seem to be mounted. I wonder whether it’s due to osxfuse volumes being “remote”

1 Like

All that is good, and it is waiting to authorise with the Browser.

If you have Peruse running and logged in to your account when you run SAFE Drive, Peruse should prompt you to authorise access, and if you agree that is when the drive will try to mount.

Did you have Peruse running? You should try with Peruse 0.7 (production, not dev), although it should work with any recent browser AFAIK because it is only being used to auth with the network.

EDIT: thanks for the OXS Fuse link which might come in handy at some point. As I read it the ‘remote’ point is just saying that FUSE is - remote - from the kernel (ie in user space) which is the case for all FUSE systems. Anyway, the problem you are seeing is not to do with FUSE at all because we have not yet authorised with SAFE network, and so have not attempted to mount FUSE. Poor FUSE, being blamed before it even gets to join in! :frowning:

@happybeing maybe my previous post wasn’t clear, apologies.
SAFE network FUSE is already authorised:

running Peruse 0.7.0 (0.7.0.245)

here’s the list of mounted drives btw

MacBook-Pro-2:~ Home$ diskutil list
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         251.0 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.7 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.7 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            105.6 GB   disk1s1
   2:                APFS Volume Preboot                 23.2 MB    disk1s2
   3:                APFS Volume Recovery                519.0 MB   disk1s3
   4:                APFS Volume VM                      4.3 GB     disk1s4

/dev/disk2 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +1.2 GB     disk2
   1:                  Apple_HFS VMware Fusion           1.0 GB     disk2s1

Ah ok. I would try revoking that and then try again, listing the steps as you go and what happens. Just so we are on the same page.

It looks though as if there is a problem with the authorisation being returned to the app (SAFE Drive).

This might be due to a difference in how Mac handles command line args, because they play a part in that dance. I don’t know how to solve that but maybe @joshuef or another Mac user can make some suggestions, and myself and @bzee can poke around.

Not having a Mac makes this a bit tricky to investigate from here, assuming that is the source of the problem. Really we need some comment from a SAFE dev who knows this area, but I recall seeing in the code (of the web hosting manager - here it is) which I think was about an outstanding issue with auth requests on OSX, so that’s my first thought - to compare what we’re doing with what the WHM does because I think it might be different.

So thank you @Stout77, if you can just confirm as suggested above, I think you can pause on trying to get something working while we look into this, but if you have notes on how the README can be improved then that would help. I can guide you in how to edit it and submit a pull request, or if you don’t want to get into that by all means just tell me what you think needs changing.

Great work BTW. It helps a lot :slight_smile:

@joshuef @krishna is the issue for this code documented, and does it still apply? I’d like to track it if there’s an open issue for it:

Thank you @happybeing,

I confirm revoking and re-running same result.

I’ll stand by and try to put together amendments to the readme (might just publish them here…not sure I’m ready for a PR :wink:)

1 Like

@happybeing openUri works on OSX now, yep!

I’ll dive in and give the safe drive a whirl and let you know where i get to :+1:

1 Like

I can also confirm, I’m seeing the same behaviour on OSX, after an auth request in the browser, the log output chugs along, but no drive mounted.

How are you handling the ipc (receiving the safe-auth: url sent from the browser?). I’m happy to play around and see if I can get this accepting the ipc, just not sure where to look atm.

1 Like

Thanks Josh. I’m still using v0.8.1 SAFE API so might that be the cause?

The auth IPC code is in safenetworkjs/src/bootstrap.js

I can’t claim any credit/blame :wink: it all belongs to @bzee. BTW the auth code works on Linux, and as of last night Windows.

1 Like

Okay cool. I’ve been triggering the pid/uri command manually with some nonsense to test (/Users/josh/.nvm/versions/node/v8.11.2/bin/node /Users/josh/Projects/safe/forks/safenetwork-fuse/bin --pid 1323131 --uri safe-auth:asdasdad and i’m seeing the following error:


######
error:  { Error: connect ENOENT /tmp/app.1323131
    at Object._errnoException (util.js:992:11)
    at _exceptionWithHostPort (util.js:1014:20)
    at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1186:14)
  code: 'ENOENT',
  errno: 'ENOENT',
  syscall: 'connect',
  address: '/tmp/app.1323131' }
connection closed 1323131 /tmp/app.1323131 Infinity tries remaining of Infinity

which looks like the ipc server isn’t reachable :frowning:

I don’t have time to dig more just now but I’ll fire in again the morning :+1:

2 Likes

That’s to be expected when using nonsense parameters. :wink: The pid will determine which IPC ‘server’ (or rather socket) to send to. ENOENT means the socket file does not exist.

Still, the node-ipc module might be the culprit here, though it should support OSX without any trouble.

1 Like

fair point @bzee :smiley:

using the pid given by the process yields nothing (beyond some logs i added). So not really sure what could be going on there.

I’ll dig a bit deeper the morn (on japan time now, so soon to bed). If you, @bzee or @happybeing have any more ideas of what to scope out let me know.

1 Like