There is a small example that shows how to create, write, and read a file in Go
There is an integration test suite that creates a bunch of files and directories to test the API. This might not mean much to most people, but I figure the Maidsafe people will welcome any integration test that tests the network (it already caught some bugs). It doesn’t cover everything, but will one day. See here on how to run it. It takes over 2 minutes for me.
Feedback and participation appreciated. I was kinda worried about putting this level of effort in something like this on such a premature release of the launcher, but hopefully it helps people write apps (Go is really easy to use).
@cretz even though I am not technical enough to understand or use them fully, the numerous contributions that you have provided lately are a pleasure to see and a real gift for the project
Looking forward to your next moves !
From your example you touch the file (create it)
Then you write “Hello World” to the file.
Is the touch necessary? In linux it would not be, but is that something the SAFE api requires? Or would simply writing to the put method work just as well?
echo "Hello world!" | go-safeclient put /myfile.txt
2016/03/16 22:27:54 Failed to write file: Server error 500: {"errorCode":-1503,"description":"InvalidPath"}
Yes, I am afraid you have to create then modify. This is the difference between /nfs/file/:rootPath/:filePath and https://maidsafe.readme.io/docs/nfs-update-file-content. You can easily just make the code do a create-then-modify and make it just look like a create normal create file (this is what the demo app does). In retrospect I probably shouldn’t have called it touch which implies it can also be done on an already existing file (which is why I have that this-is-not-posix disclaimer at the top of the repo).
Node -> Dns
-> Nfs
Go -> Dns
-> Nfs
python -> Dns
-> Nfs
Rust ..... etc.
We could use submodules to link all of these as folks do them, Making a really nice examples structure that can be tied to the API docs etc. and get as muhc feedback as possible in many languages.
I agree. One of my goals here was to expose the low level calls for what they were at a primitive level so that people leveraging the CLI calls in some bash script or something would know what’s happening. I could abstract higher, but I can just picture some “creating files with data is not atomic” bug. But yes, abstraction will be required for usefulness.
To solve that, you provide the lowest level and some appropriate higher level ones.
I just spent the last 3 days doing similar with another totally unrelated (to SAFE&crypto) system’s api calls and used bash script to prove they functioned correctly.
I am glad you are doing this for SAFE. You certainly have my thanks.
Minor issue - on Ubuntu, the conf.json was created with unusual permissions, which meant it failed to re-auth the next time I executed the command. I ‘chmod 644 conf.json’ and it resolved it.
I played with this and managed to touch, put, fetch, ls all with ease!
I just deleted conf.json and allowed it to be recreated to confirm the original permissions and they are o=x,g=wx (—x-wx—), so it looks like something odd is going on there.
Stupid octals. I have fixed this and tagged a new alpha release at Release 0.1.0 Alpha 2 · cretz/go-safeclient · GitHub. I included the Linux binary in the release this time so you don’t have to build it by hand. I am also updating the main topic to point to the new release. Thanks for the bug report.
Because those directories are not shared. Therefore they are specific to you and the app combined. There are options on the command to make them shared. Granted it is “public” (not to be confused with shared) so I believe that is why DNS can see it. I have to defer to maidsafe to explain private/public vs shared/not-shared. I also have to defer to them on the inevitable question: “if ls can only see things made per app, why can DNS see the same things created by another app?”
… just saw it in 