When creating a new thinapp in let's say, DirectoryIsolationMode=Merged, I always get some empty folders (%Common AppData%,%Personal%, %Program Files Common%,...) that have the ##attributes.ini file, and nothing else.
This file contains:
[Isolation]
DirectoryIsolationMode=WriteCopy
What causes this behaviour? I always delete those folders, to avoid strange behavious (print spooling in full isolation, mydocs being sandboxed, appdata being sandboxed), but I would like to know why thinapp marks these folders in such a way that they need this special isolation mode.
As an addition to the above correct answers:
If you take into account that ThinApp does provide 2 major solutions to application deployment:
- Distribution as a single file container
- Sandboxing 'all' changes the application makes at runtime
The main reason for problems is the sandboxing. You want to prevent your system to be 'corrupted' due to an application running (like changing registry entries or altering system files), but if you type a word document you want to be able to have this file in your 'my documents'.
The default folders you see are there to provide a basic usable platform. For all folders you don't see in the project folder (all the %...%-folders), the setting you specify during the post-capture snapshot are applied. Same for folders that don't have a attributes.ini in it, like %drive_C% often has as only a sub-folder is added.
You do NEED some of the folders to be available. For example, if you delete %SystemSystem%/Spool, you will not be able to print...! Similar having %Personal% as writecopy will have your documents end up in the sandbox instead of on your system. You will have to understand the workings of isolationmodes to be able to determine what the effect will be for deleting or even altering the default settings.
In general my experience is that the defaults are quite OK. Some things I have a different opinion about are for example the temporary internet files and normal temp files. This as it is easier to clean the system of these unwanted files and there are numerous tools doing this already, but none do this for sandboxes. Similar i want our users to share the favorites, cookies and so on with their local system, except when providing a secured browser as the users otherwise complain 'where are my' or 'why can't i'...
Kind regards,
Michael Baars - Comprehensive ICT Solutions
Please mark the question answered if so and reward points if it helped you...
Reason being it will make most applications run ThinApped simply clicking through the Setup Capture using next, next.. We want to offer the highest possible success rate, out of the box.. That said, in order to produce a ready for production package you should expect to have to modify your project.
If you want to learn about our defaults simply capture nothing with the help of Setup Capture. It will create an empty project folder with all the defaults..
More info of interest, a part from above defaults.. Any location modified will get WriteCopy and all new locations will have Full as isolation mode by default.
In addition to pbjork post, ThinApp always sets 'WriteCopy' isolation to the below folders, irrespective of 'Merged' or 'WriteCopy' isolation is selected during setup capture.
Hope this helps.
Hi,
ThinApp put this isolation mode for system related folders. It is just to avoid accidental modification of system files.
E.g. %SystemSystem% folder contains all system dlls for windows. By making DirectoryIsolationMode=WriteCopy, ThinApp assures that all modifications on this folder by ThinApped application will be reflected in sandbox and native system will remain unaffected.
If you check list given by Lakshman, you will observe that all the folders with ‘WriteCopy’ isolation mode are important folders for application and system working, so its better not to not modify these isolation modes.
As an addition to the above correct answers:
If you take into account that ThinApp does provide 2 major solutions to application deployment:
- Distribution as a single file container
- Sandboxing 'all' changes the application makes at runtime
The main reason for problems is the sandboxing. You want to prevent your system to be 'corrupted' due to an application running (like changing registry entries or altering system files), but if you type a word document you want to be able to have this file in your 'my documents'.
The default folders you see are there to provide a basic usable platform. For all folders you don't see in the project folder (all the %...%-folders), the setting you specify during the post-capture snapshot are applied. Same for folders that don't have a attributes.ini in it, like %drive_C% often has as only a sub-folder is added.
You do NEED some of the folders to be available. For example, if you delete %SystemSystem%/Spool, you will not be able to print...! Similar having %Personal% as writecopy will have your documents end up in the sandbox instead of on your system. You will have to understand the workings of isolationmodes to be able to determine what the effect will be for deleting or even altering the default settings.
In general my experience is that the defaults are quite OK. Some things I have a different opinion about are for example the temporary internet files and normal temp files. This as it is easier to clean the system of these unwanted files and there are numerous tools doing this already, but none do this for sandboxes. Similar i want our users to share the favorites, cookies and so on with their local system, except when providing a secured browser as the users otherwise complain 'where are my' or 'why can't i'...
Kind regards,
Michael Baars - Comprehensive ICT Solutions
Please mark the question answered if so and reward points if it helped you...