No @Hansachs they are not entirely different - I have ***** from helpful "knowledgable" users at both ends of the scale. In one case one such user changed the value of an environment variable (actually a VMS Logical Name) that provided the location of just such a directory. It "worked" in that it did what he wanted, in the short term, but caused that same user problems later when he used some other feature of the program that relied on the relationship between that directory and others. This is an exact equivalent to the case of changing the registry entry pointing to a directory.

No matter how "knowledgeable" we are we can not know if

1) There is some part of the program that has used knowledge of where the data directory is either directly by hard coding some or all of its name or uses knowledge of the relative paths between the data directory and some other directory such as the vghd or vghd/bin directories. I very much doubt that there are any such usages, but we do not know that there are none. (One possibility is in some old, little used part of the program that may only get used for debugging purposes)

2) That the meaning, or even the existence, of the registry entry will not change with a future release or that some feature introduces the situation described in the previous paragraph.

3) We do not know if it is "safe" to change the directory to some arbitrary name. For example the software may use a fixed size buffer somewhere to hold the data directory name. What happens if the user provides an a very long path name that causes the buffer to overflow?

4) We do not know if it is safe to change the directory name while the program is running. Perhaps different parts of the software handle it in different ways. For example one part may read the directory path from the registry during program initialisation and from then on use that value until the program exits but some other part reads it only when some particular function is first used and some other part re-reads it every time some other function is used. This would lead to different parts of the program using different locations for the data directory. Given that the program now seems to use rather more threads than it did previously such behaviour could well have been introduced quite recently.

The last could be particularly problematic if a naive user was following instructions even if they are told to exit the program before editing the registry. It has been quite obvious from previous posts that many user are not aware that closing the GUI does not quit the program even if there are no visible signs of it on the desktop.

Now, I do not think that any of these are particularly likely for the particular case under discussion, but we simply do not know.

Having spent far too much of my working life sorting out problems such as the above (and I have seen case similar to all of those that I have outlined) I am very disappointed when others suggest that doing such things, no matter how simple or obviously "correct" they are, are not a problem. They all too often have unforseen, and sometimes expensive, side effects that in the worst case only show up intermitently several months later.

Here we are arguing about the meaning of the word "hack". I remember when "hack" meant a very clever piece of code that was unmaintainable.

Whether or not modifying the Registry or the Mac Preference file is a "hack", I stongly argue that designing a piece of software so that this is the only way to make a necessary change is a poor practice and, given the size of the data folder, moving it could be a necessary change.

Does Totem have any objections to this modification?

Does Totem have any objections to this modification?

It's been discussed on this forum for years. Totem must be aware of it and they haven't said anything.