Please try to rephrase that in english with proper punctuation so that people
have a chance to understand what you are trying to say. It would also be nice if
each bug-report had a meaningful summary.

The folder that is used to store the user settings defaults to C:\documents 
and settings\%username%\My documents\ etc. this isnt allways very helpfull 
since; on most networks the my documents folder will be in a network folder, 
this way the setting follow the user round where ever they go. when the 
settings folder is created on the local machine the settings need to be 
created everytime a user uses the program on each and every machine they use 
it on. 
in other words it is saving its settings in a folder that GIMP assumes will be 
the "My Documents" Folder but isnt always. This is so because it is possable 
to move the "My Documents" folder from "C:\documents and settings\%username%
\My Documents" to where ever you want. if this just so happens to be a network 
drive/folder, a user can log on to another machine on the network and 
efectivly take their "My Documents" folder with them (And also their GIMP 
settings). This is not however the case if it is stored on the C drive as GIMP 
does. in this instance the user settings data will need to be recreated 
everytime a user uses GIMP on another Computer.
I hope this is clear enough for you to under stand.

It is clear that you don't think GIMP should always store its settings in
"C:\documents and settings\%username%\My documents".  It would help if you, or
somebody, could tell us where it *should* store its settings, and how it should
figure this out.

Changing summary to something more meaningful.

GIMP stores its settings into C:\documents and settings\%username%\.gimp-x.y,
unless one of the environment variables that affect this (HOME or
GIMP2_DIRECTORY, among others) is set or changed.

I didn't check if the environment variables that affect GIMP are documented in
the help - if not, they should be.

They aren't.  If somebody can direct me to a place where I can find the
information (it isn't in Jernej's FAQ), I'll make sure it gets into the User
Manual.  It should probably go into the FAQ too, though.

They are documented in the gimprc manpage which is also available online
(http://gimp.org/man/gimprc.html).

What i was actually trying to say was "My Documents" isnt always "C:\documents 
and settings\%username%\My documents" (or "C:\My Documents" on 9x varients) it 
would apear that GIMP assumes it is. Networks where users move around have 
the "My Docuents" else where and in a different place for each user 
eg. "\\StorageServer\%username%" obviously this causes problems when you put 
the settings in "C:\documents and settings\%username%\My documents". if you 
still cant see my point then never mind, im just trying to help. If you do 
decide to have it as a setting that you have to change per user it would be a 
good idea to put it in a place that can be easely changed via a logon script; 
such as the windows enviroment variables.

The directory can be easily reconfigured system-wide as well as per-user. The
gimprc man-page explains how to do that.

David, is this just a theoretical discussion without any proof that GIMP does
something wrong, or do you have a setup that clearly indicates that something is
wrong?

BTW, GIMP doesn't normally put any settings in C:\documents 
and settings\%username%\My documents, if this happens on your system, you
configured it to do so explicitely. And as Sven said, ways to change this have
already been mentioned - your logon script could set the environment variables.

Your comments so far haven't been very useful for understanding your problem (if
there is any), so if you want and need help, you should describe in more detail
what happens, what you expect to happen and which ways to make it happen you've
already tried.

Im my previous comments i have stated the location of the folder in which the 
settings is kept because it is the "my documents" folder that is the important 
part of the issue. I have described in 2 differnt ways the specific situation 
in which the settings folder is being stored in the wrong place (C:\documents 
and settings\%username%\My documents) not where ever windows recignises 
the "My Documents" folder to be. when you click on the "My Documents" folder 
in windows explorer it goes to a folder (usually c:\documents and settings\%
username%\My documents) However this can be changed to where ever you like. on 
our system it is set to the "U:\" drive which is a network folder 
("\\StorageServer\%username%") however GIMP saves its settings 
in "C:\documents and settings\%username%\My documents", surly you understand 
this? as you can see this is not the "My Documents" folder even though it is 
called "My Documents", just as "C:\program files\whatever\windows" isnt 
the "Windows" dir even though it is called "Windows" (unless you have some 
very kinky ideas of where to set your windows folder).

So the .gimp-x.y directory is created in "C:\documents 
and settings\%username%\My documents" on your system?

Yes, not in \\StorageServer\%username% as it should be.

So are there any environment variables (which ones?) pointing to either of these
locations?

I affraid i wont be able t let you know till monday now as its the weekend and 
i dont have access to a computer to check everything with, but i will as soon 
as i can. 

The place where you can change tle location of the "Shell Folders" is..
"HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell 
Folders\"
Within that key there are quite a few directorys that can be changed and the 
one for the "My Documents" Folder is called "Personal"
on our system it is set to "U:\" which is in turn mapped to "\\StorageServer\%
username%"

There is also a folder 
called "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Us
er Shell Folders\"
This appears to be what the system generates its "Shell Folders" form and the 
first folder i said about is the resolved values.

I Hope this helps resolve the issue.

I found some additional information related to this, so I am re-opening this bug
report.  In some cases, especially in corporate environments, the user's
documents folder is not in "C:\Documents and Settings\%username%\My Documents"
but it is set to a different place by a policy script (this is a group policy
setting).  In that case, hardcoding the path to "C:\Documents and Settings\..."
is a bad idea.  I happen to have such an environment at work (when I have to use
Windows instead of Solaris or Linux): all users have their "My Documents" folder
set automatically to a network drive.

I found several references to this by doing a Google search for the string
'location "My Documents" registry' (among the results, there is the Microsoft
KB article 221837)

This appears to be related to the registry key HKEY_CURRENT_USER
\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\
The value "Personal" controls the location of the "My Document" folder.

There is also a similar key named "User Shell Folders" instead of "Shell
Folders" and it is apparently part of the Group Policy set by the administrator.
If that value exists, the option to modify the location of the "My Documents"
folder will not available when the user views the properties of "My Documents".

Note that these keys exist for Windows NT, 2000, 2003 and XP but I don't know if
they also exist for 95, 98 or ME.  I hope that some developers who are more
experienced with Windows will be able to sort this out.

There was a mid-air collision with the previous comment with the reporter.
I hope that my comment makes sense and is not too redundant.

Ok, maybe I was not clear enough yet.

All GIMP versions I know don't put anything into the My Documents folder by
default. My question about the environment variables (as, for example, seen in
the output of the "set" command in a console window) is still not answered.

I hope that the reporter will answer your question, but in the meantime I checked
some docs and I see that Windows applications must not refer to "C:\Documents
and Settings\..." directly but should instead refer to the appropriate key in the
registry, which is usually relative to the USERPROFILE environment variable (but
not always).  I had a quick look at a Win2000 system that I use at work and I see
the key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
with the value "Local AppData" set to "%USERPROFILE%\Local Settings\Application
Data".  This value is expanded to an actual path (without the variable part) in
the corresponding "Shell Folders" key.  This is where the GIMP should create its
gimp-2.0 directory, unless GIMP2_DIRECTORY is defined.

OK, i have found where the problem originates.

COMSPEC=C:\WINDOWS\SYSTEM32\COMMAND.COM
ALLUSERSPROFILE=C:\DOCUME~1\ALLUSE~1
APPDATA=C:\DOCUME~1\DAVIDA~1\APPLIC~1
COMMONPROGRAMFILES=C:\PROGRA~1\COMMON~1
COMPUTERNAME=MSS-INS
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\davidamer
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\PROGRA~1
\COMMON~1\GTK\2.0\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 7 Stepping 0, AuthenticAMD
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0700
PROGRAMFILES=C:\PROGRA~1
PROMPT=$P$G
SESSIONNAME=Console
SYSTEMDRIVE=C:
SYSTEMROOT=C:\WINDOWS
TEMP=C:\WINDOWS\TEMP
TMP=C:\WINDOWS\TEMP
USERNAME=davidamer
USERPROFILE=C:\DOCUME~1\DAVIDA~1

we havent Set the HOMEPATH/HOMEDRIVE but the registry settings are set by the 
group profile and it would seem these enviroment variables are often over 
looked since these settings are no longer commonly used. 
However since it is the "My Documents" folder that is usualy the network 
folder in an enviroment such as ours i think the best place to keep the 
settings would be to put them in a hidden folder inside the "my documents" 
folder (read form the reistry key i said about before) also another thing that 
would be usefull is a list of all write permissions the program requires 
because secure computers have most of the file system read only. im not sure 
why but everytime i run GIMP as a standard user it comes up with the wecome 
screen/directory settup app and it has to initalise the settings again, even 
when run on exactly the same computer as the first time i ran the program 
(sorry about the change of subjcet but it is relavent)

HOMEPATH/HOMEDRIVE would give C:\Documents and Settings\davidamer, so .gimp-2.2
would be located in this place, not My Documents. Could it be that we're talking
about the startup folder in the file chooser dialog, and not about the settings
folder?

I guess we will have to work out how to find the desired location of finding the
prpofile directory, and then suggest a way to implement this in glib.
g_get_home_dir is suited for some of them, but I wouldn't expect it to return
"%USERPROFILE%\Local Settings\Application Data". 

Maybe one of the functions in
http://developer.gnome.org/doc/API/2.0/glib/glib-Miscellaneous-Utility-Functions.html
already does this, or could be adapted to return the right directory on Win32.
The interesting ones have been introduced with GTK+ 2.6, and it will be worth
trying them (e.g. g_get_user_data_dir () and g_get_user_config_dir () ). Maybe
they are already doing the right thing - but I doubt this :)

An additional problem might be caused by fontconfig, which tries to write to the
%HOME% folder by default. I don't know if it uses glib (if it does, see above),
but this is the only other part I know of that tries to write somewhere during
the startup of GIMP.

David, are you using e.g. GIMP2_DIRECTORY to work around your immediate problems?
Where does GIMP try to put the user profile data, and does it tell you if this
was successful?

David, you are saying "in a network such as ours". That makes me think that you
are a network administrator. If that is the case, why don't you just fix the
GIMP installation on your network?

*** Bug 164380 has been marked as a duplicate of this bug. ***

I am a network admin, and i could work round it, i was just trying to bring it 
to your attention. for the sake of those people who arnt. i think its always 
better to have a solid program than a bunch of hacks. No offense intended

Sorry about the gramma/punctuation in the last message i only just woke up.

I realise this bug is now over 2 years old... but it is still open and I wish to contribute.

I don't have experience with GIMP but I am the admin for a very small company network (Windows XP and Windows 2003 SB Server) and one of the people here wanted to have GIMP installed.

When installing gimp, it was immediately apparent to me that the default paths are not ideal. I however did not experience what David Amer did - the user's gimp dir is "correctly" set to C:\Documents and Settings\username\.gimp-2.2

I believe this is automatically chosen because of the value of the HOME env variable. May I suggest that the APPDATA env variable be used instead (first prize would be to read the value from the appropriate Windows APIs, as this is the most guaranteed way to get a sane value). Using APPDATA will result in "C:\Documents and Settings\username\Application Data" as the base path. This will make gimp more like all other Windows apps in where it stores it's settings. And if gimp wanted to be even *more* Windows-like then it should drop the dot in the folder name and simply use "Gimp-2.2" or somesuch - but that is neither here no there for this discussion (and might be more difficult a change to justify).

Let me now also try to explain how the networked multi-user thing works a bit more in Windows. All user profile data is stored in C:\Documents and Settings\username  (this I think most people realise already), but in other versions of Windows (such as 9x or Vista, or if in a different language) this is different (hence needing to use the registry or API calls). On a simple stand-alone computer, or a networked one that is NOT a member of a "windows domain", this is all that matters. BUT as soon as the computer is a member of a domain, extra things need to be considered. Namely that if ROAMING PROFILES are enabled then EVERYTHING in the users profile is synchronised to a network path when the user logs in and out... with ONE exception - the "Local Settings" directory inside the user's profile directory on the local hard drive (extra dirs can be excluded through registry settings). This is where the user's TEMP dir lives, as well as the IE browser cache (and Firefox has even fixed their setup to store the cache in there). This is the correct place to store transient/temporary data since it is never synchronised to the server.

Why am I saying all this? Well perhaps you've realised where I'm going with this - the gimp temp and scratch directories.

As I mentioned before - I don't actually know gimp, but just from what I read, it seems that some files could be left behind in the temp dir, and a large file could be left behind in the scratch dir, if gimp crashes. I think that for the most part end-users will not know or realise this. A problem could start to arise if files are left behind in the default locations because they will wind up being synchronised to the server every time that user logs in or out. "Each time" gimp crashes, more files will accumulate. Sure it doesn't download everything every time, but it will have to the first time, and every time a user logs onto a machine they haven't logged onto since the files were synchronised. It is best to avoid this situation, and this can easily be avoided by using the standard temporary locations on the local machine.

Now this is where my knowledge of gimp means I don't know what the best solution would be: Can the temp and scratch dirs safely be set to the same location? And would it pose a problem if that were simply the standard temp folder for the logged on user? (i.e. C:\Documents and Settings\user\Local Settings\Temp, where heaps of other junk is likely to exist as well) If this would not be a problem (in terms of file names that gimp saves) then I suggest this as the best solution. It is even a fairly easy one to implement, I believe, because all you really have to do is use the value of the TEMP env variable! In my opinion this is the best way to go because it will also happily work under Windows 9x. Although, I would advocate the use of APIs to get the location rather than the env variable.

The reason I recommend simply using the standard TEMP dir is that when I setup gimp (v 2.2.13) just now, I had problems setting the temp and scratch locations. I had chosen %TEMP%\.gimp-2.2 for scratch and %TEMP%\.gimp-2.2\tmp for temp (I put in the full paths of course but typing out the whole path here is tedious) and this highlighted a problem - gimp doesn't try to create the location! This could be a problem if one sets the gimp temp location to %userprofile%\local settings\Application Data\.gimp-2.2 because nothing inside the Local Settings folder is guaranteed to exist between sessions. Unless gimp was changed to create the scratch and temp locations, should they not exist.

I noticed someone in the comments suggested using the "%userprofile%\local settings\application data" dir as the gimp home dir - I hope it is clear now that this would be a BAD idea, since the settings would not be carried around with the user at all.

And finally - just a bit more about the whole roaming profiles thing. There are a few settings that can affect how things work. Normally the profiles are synchronised onto the local machine when logging in, and synchronised back when logging out. However it can be set such that the profile is "locked" and any changes made locally are not saved back to the server. Also, profiles can be made "local only" so that nothing is loaded or saved to/from the server at all (akin to a stand-alone machine). And finally there is a setting that will tell Windows to erase the local copy of the profile entirely when the user logs out (thus deleting all non-synchronised files).

The problem of gimp having to re-create the user data dir every time someone uses it the first time after logging on could be due to the profile not being saved to the server. This is not a gimp problem as far as I see it, but rather a system setup issue. If the network is setup such that profiles are "locked down" and don't save back to the server, then this would have been a configuration decision made by the admins and they would have to facilitate the installation of gimp for the user. The easiest way to work around this though, would be to store the gimp user dir in the user's My Documents folder, since presumably this is redirected to a network path in a situation like this. This would have to be configured manually by the user though, I would think, rather than gimp being responsible for intuiting the need for it. Although the temp and scratch paths should still be independent of the user data dir (.gimp-2.2) as I discussed above - most notably in the case of the scratch dir, where one definitely wants to avoid using a network path.


I appologise for this comment being so long, but I felt I needed to explain the situation and offer suggestions (and I have a habit of being long-winded anyway). Here is a summary of my points:

- I suggest using the Application Data folder in the user profile folder for the gimp user data dir. This, however, is a matter of good style rather than something that ought to cause any issues if left as-is.
- I suggest using the currently-logged-on user's TEMP dir as both the gimp temp and scratch dir by default (unless there are technical reasons the two dirs must be distinct) - this will ensure that a user-writable and appropriate folder is used and that it is not a network path.
- Perhaps gimp should attempt to create the paths set for temp and scratch... but I'm not sure if this is a totally desirable thing
- I suggest using Windows API calls to determine the appropriate folders for use in the above cases. This should be less of a problem during the installer since I presume it has simple means to retrieve those locations correctly. If gimp needs to read these values when it runs (i.e. when setting up data for a new user) then I don't know what hurdles are involved if gimp wants to avoid using direct Windows API calls.  I can supply further details on which API calls to use if that would be helpful.

Finally - I think it could be acceptable to use environment variables to read the appropriate path values, but I am weary of them in Windows. I saw in David's env variable dump above that his TEMP value was set to C:\WINDOWS\TEMP, which is NOT really an appropriate location for a multiple-user machine! I guess he must have enabled all-user write access to that folder otherwise things would have been very broken (or he's not using NTFS as the file-system, or only admin users log onto that machine). In any case, it isn't clear to me whether the Windows APIs would have returned the correct per-user temp folder in his case, but definitely that is not the default value and it would have been changed manually in the environment variables list or in the registry. If this is mis-configured then it isn't gimp's fault. But if this is broken then it will be broken for more programs than just gimp, so I don't think it's something to be too concerned about.

Oh, and a final finally - having gimp leave temp or scratch files behind in the correct temp folder means it has a chance of being cleared out by the Disk Cleanup wizard. If it's buried in an ordinary folder then the "gimp droppings" will remain unnoticed unless the user manually checks (never mind whether these files are synchronised over the network in a roaming profiles setup or not).

Please also check bug #171171. Perhaps the two should be merged?

I belive glib offers, or should offer, function calls for both bug reports.

If i'm not mistaken, this would be:

const gchar*        g_get_user_cache_dir                (void);
const gchar*        g_get_user_data_dir                 (void);
const gchar*        g_get_user_config_dir               (void);

These should use the Freedesktop spec, and I wouldn't be supprised that on windows they'd return the paths as described by Jerome.

Jerome, if you have some programming experience, try build a simple app that prints the results from those calls and give your input from the results. If not, I suppose we could a) read through the code, or I could run it in a virtual machine.


Either way, these function calls aren't used yet, and I believe they should. Hence the report on #171171.

FYI Jerome, with these new calls, we would end up using /gimp rather then /.gimp, since there's no more hidden dirs in /.config/* etc in linux land, which would be a positive effect here as well.

How to choose program folder is described in Windows Vista Application Development Requirements for User Account Control Compatibility: http://www.microsoft.com/downloads/details.aspx?FamilyID=BA73B169-A648-49AF-BC5E-A2EEBB74C16B&displaylang=en
Per-User Application Settings Locations can be found at page 80.
MSDN article on CSIDLs: http://go.microsoft.com/fwlink/?LinkId=71501

as of glib 2.10.2

the functions get following directories

g_get_user_cache_dir CSIDL_INTERNET_CACHE - Local Settings\Temporary Internet Files
g_get_user_config_dir CSIDL_APPDATA - Application Data
g_get_user_data_dir CSIDL_PERSONAL - My Documents

*** Bug 582690 has been marked as a duplicate of this bug. ***

*** Bug 335342 has been marked as a duplicate of this bug. ***

*** Bug 626368 has been marked as a duplicate of this bug. ***

I have just submitted a patch on Bug166643 and believe it should satisfy this bug report. For Windows, as verified on current Glib development code (2.34.0), the used directory will be CSIDL_LOCAL_APPDATA.

According to Microsoft documentation found on the web, it would usually correspond to:
C:\Documents and Settings\{username}\Local Settings\Application Data\
Which is what previous commands said they wanted to get. So all is good!

Bug 166643 has a patch in progress that is going to fix this
problem too, resolving as duplicate.

*** This bug has been marked as a duplicate of bug 166643 ***