How to modify a shared resource in a deployed file?

So I have a deployed file that has .mat files included in the shared resources/helper files section, and I want to be able to access them and modify them. I know that I could include them with the package, but I want to keep it tidy and user-tamper-proof. Thanks.

[Matthew Murphy]

For a slight explanation on the file loading described below, I am using

cd([ctfroot filesep])

to navigate to the file included in the shared resources part of the executable to load, and again to save.

Answer 1

[Walter Roberson]

It appears to me from https://www.mathworks.com/matlabcentral/answers/238308-matlab-compiler-shared-resources-and-helper-files that the shared resources/helper files section is the same as using mcc -a which is the same as "including them with the package".

The general strategy is to include the file with the package, but also have a location outside the package that you check first when you load it, using the in-package version if the other one does not exist. You would need to construct the path to the other version in some way, possibly depending on the environment variables such as USERDRIVE and USERPATH.

A shared file that can be written by the package but not by the users is a challenge, and effectively requires that the executable be granted administrative access. But administrative access on MS Windows is set in the Registry, not in any bits on the file itself, so an administrator would need to do the installation.

[Matthew Murphy]

Yeah, that makes sense. However, the problem is that the .exe needs to be able to be placed anywhere and still work normally, which is why I wanted to keep everything "in-house". The long and short of it is that I have a .mat file I use for initialization of a GUI, and I overwrite that .mat file at the close of the GUI in preparation of re-opening the window. I don't want it messed with, but I don't know how to protect it in any other way.

Also, I am running R2010b.

[Walter Roberson]

For your purpose, would it be enough to be able to detect that the file had been changed? If so, then a hash or crc or encryption scheme could be used.

There is an undocumented serialization routine that can be used as a step of that; see < http://undocumentedmatlab.com/blog/serializing-deserializing-matlab-data . Load a binary file (that the user theoretically could write to), decrypt it, verify that it passes the tests, de-serialize the bytestream to create the objects.

[Matthew Murphy]

Let me look into this to see if it's what I need. Thanks for the link.

**EDIT: OK, so here's what's going on. File loading/saving works fine. However, when I open the executable again after saving changes, it reverts to the file that is in the shared resources area. Any idea on how to stop that replacement?

[Walter Roberson]

You cannot keep the file from reverting. That is why I was talking about looking for it somewhere else and using the saved version if it was not in that other location.

The stuff about encryption and so on had to do with protecting that other version of the file against user modification.

[Matthew Murphy]

Ah, I get it now. Thanks for the help.