Today, I encounter small problem with "TaskCoach Portable". All this started dialog with John about how PortableApps interact with each other and what is the purpose of other directories like 'Documents' and "AppNamePortable\settings".
The original thread can be found here:
https://portableapps.com/node/13290
John,
Thank you very much for taking time to explain to me what was idea behind the chosen tree structure for PortableApps. Now I better understand how it is working.
At the same time I still have some concerns and I will appreciate if you or any one with more experience help me to find solution.
Currently I use TrueCrypt to encrypt the whole disk. This only works if I have 'Administrator' rights or TrueCrypt is locally installed. This is not very practical in the most cases. I would like to use other tool that decrypts my personal files when I start PortableApps and encrypt them back when I close the menu. The problem I have is that 'settings' directories are spread as sub-folders under individual applications. I really like to encrypt 'settings' directories because there is a lot of personal information.
It would much easier if there is directory 'PortableAppsSetting' and each application has own sub-directory there. This is like the 'Application Data' directory in user's windows profile.
Thank you very much!
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
But I was also thinking, if people do a stand-alone install, things aren't going to work right. If you want, just have a batch script move them there on exit or something.
Insert original signature here with Greasemonkey Script.
Yes. Last night I created a script and it worked. But here is my observations:
1. Moving directories with script takes time and if the user is not patient to finish he/she will end up with corrupted file tree.
2. My test also found that using the script makes the system unstable because the racing conditions. For example Firefox needs extra time to unload it settings and store them in to 'settings' directory. If the script runs during this time again it corrupts the application.
3. Moving directories increases the ware on flash USB drives.
At the same time I agree that in stand-alone install 'settings' directory should be inside application directory.
So I was thinking that solution should be intelligent one. I will try to spell it out and I will appreciate every one to voice their opinion.
The basic concept would be something like this:
1. The launcher should be aware of the type install that user uses. For example if the program is lunched from directory like 'X:\PortableApps\AppName' we can assume that is part of the Portable Suite. Other wise it is in stand-alone mode.
2. If the user uses the Portable Suite the luncher should use 'PortableAppsSetting' directory (it could be sub-folder of 'Documents' folder.
3. If the user uses stand-alone install the luncher should use 'AppName\Settings' directory.
4. The PortableApps Installer program should also be aware about user setup (see item #1). And install and modify app's setting in the 'right' folder.
All that does not seems to be very difficult to do, but often things become really complicated when you try to implement them.
Given that your original requirement was to centralise all of the user settings so that you can encrypt them, there are some flaws in your observations and thoughts.
1) If the move is done with the correct syscall, it should be a very short operation, shifting a single folder to a different place in the directory tree. The time for this is negligible. Certainly minimal in comparison to encryption times.
2)This time taken to write the settings is just as big a problem for encryption - if you start to encrypt files while they are still being written, that is a real recipe for disaster, including the possibility that the file could be encrypted, and then the app opens, writes, closes, leaving un-secured data on the drive that you think you have made safe
3) Moving a directory should be a simple rename operation, consisting of basically two writes, one to the source directory, and one to the target, shifting the reference to the subdirectory.
Also, many of your assumptions about "intelligently" automating some of this in the launchers will break the systems for many existing users.
For example, many people have PortableApps installed as part of the Suite on a hard drive but not in the root of it. Other people have more than one installation (for example for testing, development, backup, user home directories), and it would not be possible for them to always have it in a fixed location.
If the launcher looks in completely different places for settings depending on the exact path to the launcher, it will make debugging user problems significantly more difficult.
Finally, you may be interested to know that many / most of the launchers already support an ini file placed with them, and a very common entry in them is "SettingsDirectory" which allows the user to move some of the settings to a place of their choosing.