I don't think this issue is particularly tied to "XP home edition" as many people have been able to run gnucash from the installer on XP home. (Me, for instance.) I'd rather think this is yet another duplicate of bug#457100, unfortunately. Can you check whether any of the workarounds there (esp. deleting that ior file in the last comments) would change anything for you?

Christian, are you sure about that bug?
I think there are two different issue, one with a fatal warning (bug 457100) and one with startup taking a very long time (bug 449153).  This here sounds more like the latter and I cannot remember reading that deleting the ior file fixed it.

Does deactivating some network interface or firewall help?
If yes, may you give us some information about your network setup?  Maybe the output of "ipconfig /all" and other relevant stuff?
Thanks!

I believe that this bug is probably related to comment <a href="http://bugzilla.gnome.org/show_bug.cgi?id=449153#c">22</a> by Ed and comment   <a href="http://bugzilla.gnome.org/show_bug.cgi?id=449153#c27">27</a> and <a href="http://bugzilla.gnome.org/show_bug.cgi?id=449153#c28">28</a> by William on <a href="http://bugzilla.gnome.org/show_bug.cgi?id=449153">Bug 449153</a>.  In this case, crucial directories are created with incorrect permissions, causing gnucash-bin.exe to immediately terminate.  I have confirmed that this is a problem for me with both GnuCash 2.2.0 and GnuCash 2.2.1.  However, I also believe that <a href="http://bugzilla.gnome.org/show_bug.cgi?id=449153">Bug 449153</a> as originally filed by Steve is a different problem.  In later comments, it is clear that Steve is able to delete .gnucash, .gconf, .gconfd, etc., which would not be possible if he was having the same permission problems.  I do not know why some people seem to have problems with permissions while others do not (Windows 2003/XP permissions are really complicated!)  I keep my machine in Simple File Sharing mode normally, but I turned it off to confirm the permissions of the folders in question (more on this below).  Performing the fix outlined in <a href="http://bugzilla.gnome.org/show_bug.cgi?id=449153#c28">comment 28</a> is just a fast way of adding the user COMPUTER\user with all permissions set to "Allow" (except Special Permission, which remains cleared).

As an experiment, I uninstalled GnuCash and removed all of the folders in question, then attempted to reinstall with Simple File Sharing turned off. However, I experienced the exact same problem.

When I first try to run GnuCash it only creates C:\Documents and Settings\user\.gnucash before exiting.  Just for the record, "user" is an Administrator on my machine.  There is one group on the Access Control List (ACL) for this directory; SYSTEM has Full Control, set to Allow, inherited from C:\Documents and Settings\user.  Permissions for ...\user are as follows:

1) SYSTEM has Full Control set "Allow", not inherited, and applied to "This folder, subfolders, and files"
2) COMPUTER\user has Full Control set "Allow," not inherited, and applied to "This folder only"

OK, so as a Linux user I find it really bizarre that files and folders created in the home directory are not supposed to automatically inherit permissions giving user Full Control.  However, I have to assume that this is a default behavior based on the facts that several users seem to have this problem and that I try to keep my Windows system as "vanilla" as possible (I have not changed any permissions on these folders, I only use Simple File Sharing).  I haven't had any problems from this because folders such as My Documents and Desktop inherit Full Control for COMPUTER\user from some mysterious "parent object" and this inherited permission applies to all subfolders and files.

I've noticed in general that Windows programs do not keep settings etc. directly in the home directory.  In fact only one application, Rainlendar, makes a folder in ...\user and it explicitly gives COMPUTER\user Full Control of the folder it creates.  Rather, they usually keep these things in the hidden Application Data or Local Settings\Application Data directories.  On my system, both of these folders inherit correct Full Control permissions for COMPUTER\user from the mysterious "parent object," just like My Documents.  So it might be wise to change GnuCash (and the other software, like gconf) to store files in the correct directory (whatever that may be for a Windows system).

OK.  So you say that you if you delete those directories and start gnucash, it will still recreate them with incorrect permissions?
Does setting the environment variable GNC_DOT_DIR to "%USERPROFILE%\App Data" fix that?  In case that is true, we need
(1) a source stating that our choice is definitely incorrect
(2) a way to determine that directory name (mine is called Anwendungsdaten)
(3) fixes to gconf, libgnome, gnucash...

Oh, please note that GNC_DOT_DIR controls the location of .gnucash, for obvious reasons :-)

Re bug 466512 comment 3 ;-)

(In reply to comment #3)
> When I first try to run GnuCash it only creates C:\Documents and
> Settings\user\.gnucash before exiting.  Just for the record, "user" is an
> Administrator on my machine.  There is one group on the Access Control List
> (ACL) for this directory; SYSTEM has Full Control, set to Allow, inherited from
> C:\Documents and Settings\user.  Permissions for ...\user are as follows:
>  
> 1) SYSTEM has Full Control set "Allow", not inherited, and applied to "This
> folder, subfolders, and files"
> 2) COMPUTER\user has Full Control set "Allow," not inherited, and applied to
> "This folder only"
> 
> OK, so as a Linux user I find it really bizarre that files and folders created
> in the home directory are not supposed to automatically inherit permissions
> giving user Full Control.  (...)
> 
> (...) On my system,
> both of these other folders inherit correct Full Control permissions for
> COMPUTER\user from the mysterious "parent object," just like My Documents.

So far we've only used for directory creation what the glib library offers for us, which is the g_mkdir() function: http://library.gnome.org/devel/glib/unstable/glib-File-Utilities.html#g-mkdir That function is called in gnucash's src/engine/gnc-filepath-utils.c in gnc_validate_directory().  If you have any suggestion what we should use instead of g_mkdir() in order to achieve the correct permissions, we would happily use that.

(In reply to comment #7)
> If you have any suggestion what we should use
> instead of g_mkdir() in order to achieve the correct permissions, we would
> happily use that.

I've found the answer from the glib side by myself: We can't handle the ACL permissions through glib. It says e.g. at g_access():

> On Windows, the underlying access() function in the C library only checks the 
> READONLY attribute, and does not look at the ACL at all. Software that needs to > handle file permissions on Windows more exactly should use the Win32 API.

How would the appropriate Win32 API look like...?

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

Comment#3 means that we still need to fix Permissions when creating gnucash (and all the other) directories. No idea how to do this, but clearly it is a bug.

Maybe at least for the .gnucash directory on #ifdef G_OS_WIN32 we should use the function CreateDirectory() from <winbase.h>, see http://msdn2.microsoft.com/en-us/library/aa363855.aspx

The last comment on this bug was added 10 years ago. There haven't been any other reports of this directory being created with improper permissions since. Is this really still an issue with gnucash 2.6.17 ?

Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=466512. Please update any external references or bookmarks.