Default location for user vaults conflict

[Dan-Schmidt]

The default location for vault storing space is the same for every user in the UI. This causes a problem after one user has created a vault in a particular machine.

[Viv-Rajkumar]

Given a base path (In this case GetSystemAppSupportDir() / "Vault-Store"), lifestuff can just create a folder inside it with a name from for example

RandomAlphaNumericString(64) or RandomUInt32()

and make sure such a folder does not exist. This should then solve your conflicts issue??

[Dan-Schmidt]

My opinion is that we should leave that field empty in the UI. Thus, if a path is indeed passed in, it'll be used, otherwise, the path should be empty and the library will choose internally.

[Viv-Rajkumar]

I don't think we can do that. It was our requirement to let the user be able to see the default location if they choose to and allow them to change it or accept it

Not showing the default location is one not very user friendly,

Also with our current restrictions in P1 of not being able to change store location after credential creation, this was picked as the approach we'd go with considering multiple other things as well like os installed on boot-up ssd's that people do not want filled and few more reasons.

If your wanting just the create user api call to have the field left empty but show the path to the user, we'll need the api expose a function or variable to parse and show expected path to user to keep api and ui in sync.

^^ think creating a random folder in any given base path is still required if the user or users on same machine give same custom path for both their stores.

[Dan-Schmidt]

Ok, good points.

I think we need to get the people doing invigilator/vaults involved, to decide which lib is best placed to make the decision on the name. Lifestuff can do it, but it's really only passing the path to the CC, which sends it to the invigilator, which gives it to the vault.

[Viv-Rajkumar]

I think for now you can do this in LifeStuff dan. I've already checked it to be fine with David for this to be in Lifestuff. We don't have the time to pull all you guys together for this issue just now.

If things change I'll give you a shout

[dirvine]

My feeling si the screen is too big and this options should be visible if clicked, but not obvious at all. It is perhaps something we should allow changing of via the gui (vault manager screen) as once we set it here then we fix it. In that case I would imagine the gui would pass to lifestuff manager a new set of parameters for the vault. We should though try and make sure the vault copies it chunk store to the new location as well.

This is likely a classic case of us documenting the change we want and passing it (api defined) to the dev team respective members as tasks on tracker. Here is my quick example

Change Request 1

Description To allow the user to select on install a vault location different form default.

Libs affected LifeStuff Add an API call bool SetVaultLocation(boost::filesystem &user_selected_vault_location) return true on success

Private lifestuff_manager Add an API call bool SetVaultLocation(boost::filesystem &user_selected_vault_location) return true on success

PD Add an API call bool SetVaultLocation(boost::filesystem &user_selected_vault_location) return true on success Change Request 2

Description To allow users to change vault location at runtime

Libs affected Lifestuff-GUI

etc. ....

I hope you get the idea, let me know if you agree as launch manager and QA manager ? (i.e. wearing the appropriate hats)

Best Regards David Irvine

http://maidsafe.netmaidsafe.net Limited is a limited liability company incorporated in Scotland with number SC297540. VAT Registered 889 0608 77. Registered Office: 72 Templehill, Troon, KA10 6BE. Telephone Scotland: +44 1292 750020.

On Thu, Nov 8, 2012 at 10:26 PM, Dan-Schmidt notifications@github.comwrote:

Ok, good points.

I think we need to get the people doing invigilator/vaults involved, to decide which lib is best placed to make the decision on the name. Lifestuff can do it, but it's really only passing the path to the CC, which sends it to the invigilator, which gives it to the vault.

[Viv-Rajkumar]

Vault location details are like you said not too obvious even now. Default path/ choose custom path is only shown upon the user clicking "advanced options" while creating his Id. If they just spam next in the wizard they don't see anything

If vault location can be changed at runtime after credentials are created then yeah I'm pretty sure Stephen wouldn't mind starting off with a default location, my only concern is time needed for this and if its a must-have feature for P1

[dirvine]

Maybe, but if we create the appropriate docs (very short 1 pagers) we can find out exactly how long it would take (within reason) and decide from there.

I am not suggesting an either or, I am suggesting both ?

I feel this is exactly what we need from QA (Dan) to give us half a chance with stuff like this.

Best Regards David Irvine

http://maidsafe.netmaidsafe.net Limited is a limited liability company incorporated in Scotland with number SC297540. VAT Registered 889 0608 77. Registered Office: 72 Templehill, Troon, KA10 6BE. Telephone Scotland: +44 1292 750020.

On Thu, Nov 8, 2012 at 10:57 PM, Viv-Rajkumar notifications@github.comwrote:

Vault location details are like you said not too obvious even now. Default path/ choose custom path is only shown upon the user clicking "advanced options" while creating his Id. If they just spam next in the wizard they don't see anything

If vault location can be changed at runtime after credentials are created then yeah I'm pretty sure Stephen wouldn't mind starting off with a default location, my only concern is time needed for this and if its a must-have feature for P1

— Reply to this email directly or view it on GitHubhttps://github.com/maidsafe/MaidSafe/issues/61#issuecomment-10208832.

[Viv-Rajkumar]

Both sounds great to me :)

[Dan-Schmidt]

I agree that we should do a more detailed analysis. Considering the implications to a vault changing location would be interesting. It may turn out that we need to stop vaults, who knows.

In the short term, I think putting the decision in the hands of the component that handles the running of vaults seems the most appropriate, ie, the ls-mananger.

On the changing of the location API functionality, I share Viv's opinion, and I think we should postpone the changes to P2.

On 8 November 2012 23:08, Viv-Rajkumar notifications@github.com wrote:

Both sounds great to me :)

— Reply to this email directly or view it on GitHubhttps://github.com/maidsafe/MaidSafe/issues/61#issuecomment-10209227.

Regards,

Dan

maidsafe.net<http://www.google.com/url?q=http%3A%2F%2Fmaidsafe.net&sa=D&sntz=1&usg=AFrqEzeW1FH1rVQichzSX-AZsEnlBq55Gg>Limited
is a limited liability company incorporated in Scotland with number
SC297540. VAT Registered 889 0608 77. Registered Office: 72 Templehill,
Troon, KA10 6BE.
Telephone Scotland: +44 1292 750020.

[muecs]

We'd indeed have to stop the vault in order to move the ChunkStore, since it's used by a lot of components in PD. Stopping the vault releases the chunk store, then we'd move the whole chunk dir via file system calls, and re-start the vault with the new location. We could do that from the client, that way we can give better feedback on progress and potential issues.

[Dan-Schmidt]

One thing that I think needs to be addressed is that right now the communication with the vault is 100% through the ls-mgr, which can only be done when using the same machine where the user was created. So the work that we'd need to do to change the CS location will probably also involve having direct communication between vault and client.

[muecs]

The foundation for sending administrative commands to a vault via RPC is there (at least on server side), it just needs to be extended for this particular scenario. I imagine the piece of code needed to move the CS would be identical, whether triggered by ls-mgr or RPC.

[Fraser999]

Fixed in https://github.com/maidsafe/MaidSafe-Private/commit/0664580aa1828574a0fa3f7cc1f6ed304585fd81 and in https://github.com/maidsafe/MaidSafe-Private/commit/be32ce2e437243069fa9c65e0f188d6cd130e3cf