I agree with Marcus, it's weird the path is hardcoded... This way i cannot include it in an automated backup either.
Please support customizable paths in a future update?
You might consider using the mSecure backup and setting its location for your automated backups. My guess is that the mSecure database would be problematic as part of a backup/restore strategy whereas all you need to do with an mSecure backup is to reinstall the program and restore the data.
Hi guys,
Unfortunately, or fortunately, I don't know, the database file for our UWP app relies on more than just the database file itself (mSecure.mscf). It depends on other files/folders/settings in the \mSevenSoftware.mSecure10_xxxxxxxxxx\ folder as well. Because of this, the database file is pretty useless outside of it's default hardcoded path. Since that's the case, there really is no reason for us to allow you to move the default location of our database file to a custom location here.
I'm not sure if the purpose of moving or storing the database file is simply to have secure backups of the database file here or to sync the database file across multiple computers. However, either way, we have sync and backup options in either case that you can and should use instead. In the near future, I hope to also have our Sync with a shared folder option backup on Mac and Windows to allow customers using computers to use any sync services (I use Nextcloud myself) they'd like in order to keep their information in sync. Unfortunately, the Sync with a shared folder option will continue to be unavailable for mobile devices :-/
I agree with Marcus. Eden, many of us prefer to specifically control the location of data. We have various motivations; mine is to centralize and rigidly control my data bucket. On the desktop side, I wrap all "mission critical" data, including my .mscw within a Veracrypt container. Your choice to hard-code the 5.5 data path might be well intentioned, but for me it's a limitation that keeps me at v3.5.x.
Based on Mike's response above, it appears that mSeven is not interested in addressing this issue in any way; it's been 3 years since any communication about this issue. I agree with Gerry! This, along with a litany of other issues is why I have not taken the step to commit to mSecure 5 (or beyond). You have violated our trust with your implementation of mSecure 5 by "killing" proven functionality we came to rely on in 3.5.7.717, with this being yet another violation. You could have offered to EXPOSE the location of the data file, but have not, causing personally-responsible me to spent hours Googling and hunting for "MY" data file. I FINALLY FOUND THE DAMN THING!!!! We need to know where OUR data resides PERIOD! You do not get full-reign over our critically important personal information!!!! If you think you have that right to our security, and destiny, please advise. I will decide whether to continue our relationship. This needs to be addressed pronto! Please be advised that I've not received any benefit for the money I've paid for mSecure 5, as I've not used it since paying for the pre-release.
Marcus
Hi Folks,
currently it looks as if msecure 5.5 makes use of a hardcoded path to store the msecure database. Path looks like "C:\Users\<USER>\AppData\Local\Packages\mSevenSoftware.mSecure10_xxxxxxxxxx\LocalState".
It would be great if it becomes possible to customize the path where the database should be stored. I used msecure (older versions) for a long time and I used it in conjunction with truecrypt/veracrypt and I put the database in an encrypted container file.
Kind regards
Marcus
3 personnes aiment cette idée