Can I suggest starting to take a look at our drive lib Mark, it will use rust-fuse and we will supply a bunch of code to mix in cbfs (for windows) eventually moving forward with the new MS open source libs. Fuse stuff is nice and we will be in there after next sprint. It will give you a great heads up in how we can easily supply portable apps. You can also look at our c++ version to see how this will happen.
@dirvine David, are you suggesting I work on it or learn from it? If former, what do you have in mind?
Work on it, I would suggest playing with rust-fuse for a start. You can for instance connect it to self_encryption and play around a little. In a few weeks we will hammer the drive lib (not needed for launch) so you get some time to see and get a feel for it. We then connect that to the users account and mount the root dir there and you will see the client lib providing the directory handling. It all really pulls together then and is obvious. It’s also very interesting as well as you will see your whole computer virtually will exist in memory and being able to share drives around and having some read_only for public shares means your innovative ideas will flow.
So play really and when your comfy with fuse then look at our c++ drive lib and you will quickly see how we achieve a local virtual drive. It’s also a lib we will try hard to make generic like we are with all our libs (that do not start with maidsafe_) and the hope there is other projects can make use of these. I see crust being super useful for man projects and drive a close second (cross platform hard disk is super useful).
OK boss will take a look. Welding tomorrow though… I hope, and a busy next few days.
Did my first TIG welding today and more tomorrow, but in the mean time I’m taking a peak at this.
Here’s my understanding/guesswork:
- rust-fuse - usage: implement a Filesystem trait, which then allows an alternative storage medium to be mounted on the OS and used as if it is part of the device filesystem. [Q: rust-fuse on Linux/OSX, cbfs on Win?]
- takes a stream of data, encrypts stream as chunks with are stored via series of PUT(key/chunkname, value/data), and returns a datamap.
- takes a datamap, retrieves data via series of GET(key/chunkname) and decrypts to return a stream of data
- maidsafe_Drive - I’m guessing that this passes a Storage object [Q: implemented based on the SAFE RESTful API = key/value access to SAFE?] which is passed to SelfEncryptor.
I’m not sure what you are suggesting I do:
In playing with rust-fuse, implementing the whole Filesystem trait is onerous, although I can imagine just implementing file (open/read/write) if that would work on its own. Then connecting rust-fuse and self_encryptor could mean using SelfEncryptor to map the Filesystem (file open/read/write) to a datamap/chunkstore for the file using ordinary filesystem calls. The result would be a mount directory where any files stored would be saved in a reserved folder on the filesystem (as a datamap/chunkstore for each virtual file). I’m not sure if this would work (just implementing file open/read/write) or if you had something else in mind when you suggested connecting rust-fuse and self_encryptor?
Anyway, before looking at Drive, that’s where I am. Am I along the lines you were thinking, or has this whiskey fuddled me brain?
Perfect Mark, the simpler the better for now. Then we will connect self_encryption and do some neat tricks. BTW I read wedding at first
I’m trying to get my head around what Drive C++ is, and is not, and decided to try building it.
Is it buildable? I get an error with cmake about protoc, and again while building drive:
[ 86%] Built target maidsafe_drive_launcher make: *** No rule to make target '/home/mrh/src/maidsafe/src/drive/protoc', needed by 'GeneratedProtoFiles/maidsafe/drive/proto_structs.pb.cc'. Stop. CMakeFiles/Makefile2:8830: recipe for target 'src/drive/CMakeFiles/maidsafe_drive.dir/all' failed make: *** [src/drive/CMakeFiles/maidsafe_drive.dir/all] Error 2 Makefile:127: recipe for target 'all' failed make: *** [all] Error 2
PS Still welding, not wedding
Ah the c++ Drive lib never converted to ceraal from protoc, you won’t be able to build that now unless you went back in time in github to last October perhaps. I would nto bother though. There is gonna be a drive project happening soon so readme etc. is about to update to show that. It’s best to wait a wee while and jump in there. You will see readme’s now getting lib maintainers listed. So we have targets to ask questions of now