Hi @drehb , thanks for that.
I used VS 2019 Preview 3-4, but they are interchangeable. Never had to add any global.json though, maybe that’s something of 2019 RC?
I was about to make a nuget for SAFE.AppendOnlyDb, but it’ll be in next version, so it can be restored without hassle.
Anyways, thanks!
That’s right, and for Username and Password it’s 3/3 IIRC. But it doesn’t have any feedback there either. It will all come though
And it’s not a sane validation, so more effort will go into that part as well.
Sure absolutely.
[user]/appdata/local/temp/MockVault
Just delete it
There’s a db file in the exe folder that you want to delete as well. There will be one per drive.
If you are willing to take the hit (I wouldn’t recommend it though, but in case you are) maybe you can try reproduce the BSOD on renaming/moving the first folder? Haven’t confirmed that it’s happening on various machines. It’s likely not something I will be able to do much about, but I can still collect more information to the dokan team so that they hopefully can get it pinned down.
EDIT: I updated the instructions now, here and on the release page.
Except from some issue purely on dokan side, there’s a possibility that something indirectly is configured in a way that would lead to this.
I have since a while ruled out direct implementation error, as when debugging, it does not even reach my code from the driver - the error happens before it.
So I will need to spend time finding out from other dokan users (or the maintainers) what could possibly be configured/done wrong on my end as to indirectly lead to such. Alternatively encourage them to fix an issue they’ve had since 2017 that they suggested as related, and hope it really was.
I’ve thought since I saw it a couple of weeks back that it’s not the lowest hanging fruit of this tree, so I will probably not get bogged down with that quite yet, and instead continue focus on developing the rest of the application.
Here’s a short video (6:47 min) showing the use of SAFE.NetworkDrive:
For all audiophiles out there: the sound is much better than previous videos. I’ve got a dbx286s mic preamp and an AT2035 mic so things are naturally a lot better. I’ve never worked with audio before, so I’m still struggling to get a good sound. It seems to me that it’s still not quite what it could be given the equipment? Feedback on what’s amiss in the sound is appreciated!
Lookin nice, but if we want people to use this to backup things it must be as efficient with puts as possible, not to mention foolproof.
Also I have the idea that there are a confusing amount of password prompts, I do get why they exist, but I also suspect most people will be annoyed and keep losing the keys to their drives, resulting in a negative experience.
Maybe you can simply ask for one password for the manager and do some mathy magic (I’m not a mathmagician) to get a name for its files?
It would decrease complexity even further and thus more foolproof.
It’s going to be very efficient with the upcoming changes. I mentioned it in a previous post above.
So the thing now is that data would be transferred from one drive to another. That is wasteful. The way it will happen instead is that we just transfer a single datamap which points to an immutable data with the snapshot of the filesystem, which itself is just the folder hierarchy and pointers to the actual data - i.e. quite small size of the data. Btw, here you can see current progress on snapshotting - which is a required feat for this - in SAFE.AppendonlyDb repo:
What all that means is we would basically just share a shortcut to the actual data, instead of copying.
It is then pretty much as efficient as it can be I would dare to say.
I agree, it can definitely be simplified. There’s certainly a large user group that would prefer it that way, and they would be the priority focus. More tech savvy people could be catered to with more knobs and dials for increased configurability, in some opt-in advanced version view.
You’ve got a good idea there.
We could do something like this:
To login, enter one password.
Any credentials for drives are derived out of that password and the drive letter.
So you just press add, and you’d get a new drive.
How about that?
On another note: an issue with the current way we pick drive letter, is that we can only access a drive based on what available drives you have locally. So say you have connected a physical drive on D, and you also have a D drive on SAFE.NetworkDrive. Currently, as long as your physical drive is hogging that drive letter, you won’t be able to access the SAFENetwork drive of same letter from that machine. So, I need to come up for something there as well.
How about solving that by simply going backwards? z,y,x.
Unless someone has them all used or using another program to add a virtual drive it should simply fix that.
Though then you can’t give someone else acces to one drive, unless you show the generated credentials in plaintext.
Yep sure, going backwards would avoid the conflicts in most cases. I think I’ll do like that actually. As you say, only if someone is adding drives through other program with the same scheme for picking drive letter, would you get the same type of conflict. Or naturally if all letters are taken, but that would always be a problem
This is true. So, maybe we’d add an option like: “Create shareable copy from this drive”
So, behind the scenes, it’d just create some random password, generate the SAFENetwork credentials, create the drive, compress and copy over the snapshot to it, and output this random password in a format of choice (to clipboard or send it via SAFEMessages app … )
Basically, for the user it’s just: right click the drive, type in the other userid, and they get a message with the password to a new drive with the data.
Great progress @oetyng. This is super. Presentation was also good and the vid is right about the goldilock zone in terms of giving enough details yet not being too long.
I also agree re:limiting number of credential inputs at least for the fool proof mode.
I’ll need to evaluate the security of the implementation, there are some compromises being done currently. So, will have to see if it’s good enough or needing changes.
