03-07-2018, 09:30 PM
So far it is not clear whether or not I have a problem. My results differ from yours slightly and I thought your opinion about my status is better than mine. To start I know enough about Linux to know what $HOME means in that case. I don’t see an analogy in Windows.
Here is a link to a set of screenshots. They represent doing the same thing in both standard/normal mode and what we’re trying to achieve here which I’ll call portable. Insofar as Linux goes, I don’t think there is any way to do what we’re talking about in that environment. I don’t think Linux is even able to execute anything stored on media formatted with a Windows based file system (like you find on all jump drives). There is no such thing as "execute" permission on such file systems.
If I simply start GIMP both normally and the way we’ve discussed herein the console display contains only one line that is different. To see it you only need to look at this screenshot for the startup in portable mode. Line 13 (not counting blank lines) where it says “Failed to parse tag cache: No such file or directory” is the only difference. Given the number of other errors displayed on this screen that is not too alarming. However the bigger discrepancy between the 2 modes of starting GIMP has to do with the folders that get created. Here is a screenshot which shows what results in the way of new files/folders being created on the system (i.e., C
drive. While I cannot compare this directly with the screenshot you made it does show a folder named “2.9” within the top level GIMP folder as does yours. However, this screenshot shows what gets created when I tried my portable startup with “GIMP2_DIRECTORY” referencing my folder named “\MyWin\GIMP\W64\UserData\GIMP”. Notably absent is the sub-folder named “2.9”. When I view the menu item Preferences>Folders what look like the corresponding sub-folders under “2.9” point to precisely where they should. There are just no folders defined at that location. All it took in the case of normal operation was to complete startup for such folders to be newly created. In that, my experiment made sure those folders were absent when running the normal startup.
Insofar as those folders are all empty after completing the normal startup this may not be a problem as long as they can be written to when needed. Any ideas?
Here is a link to a set of screenshots. They represent doing the same thing in both standard/normal mode and what we’re trying to achieve here which I’ll call portable. Insofar as Linux goes, I don’t think there is any way to do what we’re talking about in that environment. I don’t think Linux is even able to execute anything stored on media formatted with a Windows based file system (like you find on all jump drives). There is no such thing as "execute" permission on such file systems.
If I simply start GIMP both normally and the way we’ve discussed herein the console display contains only one line that is different. To see it you only need to look at this screenshot for the startup in portable mode. Line 13 (not counting blank lines) where it says “Failed to parse tag cache: No such file or directory” is the only difference. Given the number of other errors displayed on this screen that is not too alarming. However the bigger discrepancy between the 2 modes of starting GIMP has to do with the folders that get created. Here is a screenshot which shows what results in the way of new files/folders being created on the system (i.e., C
drive. While I cannot compare this directly with the screenshot you made it does show a folder named “2.9” within the top level GIMP folder as does yours. However, this screenshot shows what gets created when I tried my portable startup with “GIMP2_DIRECTORY” referencing my folder named “\MyWin\GIMP\W64\UserData\GIMP”. Notably absent is the sub-folder named “2.9”. When I view the menu item Preferences>Folders what look like the corresponding sub-folders under “2.9” point to precisely where they should. There are just no folders defined at that location. All it took in the case of normal operation was to complete startup for such folders to be newly created. In that, my experiment made sure those folders were absent when running the normal startup.Insofar as those folders are all empty after completing the normal startup this may not be a problem as long as they can be written to when needed. Any ideas?