Does anyone know why the installer tries to resolve directories which are NOT targeted (is this a bug?), and if it does so, is there any workround or defensive programming that can be used?
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Problems with Directory Table
Started by
ianmw7
, Nov 20 2001 12:49
6 replies to this topic
ianmw7
-
- Members
- 55 posts
Posted 20 November 2001 - 12:49
Cost Finalize resolves entries in the directory table for "all target directories" according to the docs. We have a major user currently having problems with installation that we have traced to his having 2 personal folders referring to a drive that doesn't exist. Neither of these are used by the install, (nor, clearly, by the user, else he would have found this out earlier). but they still cause the installation to fail, with the usual incomprehensible error messages.
ianmw7
-
- Members
- 55 posts
Posted 23 November 2001 - 15:14
This appears to be quite serious. The user in question has shell directories which point to drives which "exist" only when he is connected to his network. This is obviously going to happen frequently, and urgently needs a solution. Any ideas? Could it be because we create empty directories (and therefore have to use the directory table) that this happens? - i.e. without these directories would the installer ignore the directory table altogether? Anyone know?
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 23 November 2001 - 17:31
Examine your msi fiel with Orca to find out whether any of these not existing folders are referenced in the directory table.
Also all directories listed in the target machine's PATH environment variable should exist and be accessible.
Also all directories listed in the target machine's PATH environment variable should exist and be accessible.
ianmw7
-
- Members
- 55 posts
Posted 26 November 2001 - 11:39
Thanks for the suggestions, Stefan, but with respect, I don't think they answer the question - unless you're saying that all the default entries in the directory table which are not going to be used by the install should be removed. Are you saying this?
It's also commonplace, esp with laptops,. to refer to drives which "don't exist" when they are not connected to a network. Admittedly, in my experience, (I do a lot of work from home - where I may or may not be connected to a second network), this simple fact seems to have escaped Microsoft - maybe it doesn't happen in the States? - but for years I've had to find all kinds of workrounds due to the fact that sometimes I'm connected directly to a network, sometimes by phone, and often not at all. Even with WIN2000, Windows frequently hangs when using Outlook or IE if I'm not very careful with connections.
So I don't really see how this solves the problem, though I'm currently trying to narrow down the conditions under which it occurs.
It's also commonplace, esp with laptops,. to refer to drives which "don't exist" when they are not connected to a network. Admittedly, in my experience, (I do a lot of work from home - where I may or may not be connected to a second network), this simple fact seems to have escaped Microsoft - maybe it doesn't happen in the States? - but for years I've had to find all kinds of workrounds due to the fact that sometimes I'm connected directly to a network, sometimes by phone, and often not at all. Even with WIN2000, Windows frequently hangs when using Outlook or IE if I'm not very careful with connections.
So I don't really see how this solves the problem, though I'm currently trying to narrow down the conditions under which it occurs.
ianmw7
-
- Members
- 55 posts
Posted 26 November 2001 - 13:30
Stefan - I've managed to discover the following:
I cannot reproduce the problem under WIN2000. However cunningly I try to point the shell folders at non-existent /disconnected/shared then unshared drives, the system always returns them to their orignal value - at least, after trying an install, there they are back again. So this may be a WIN98 problem only (which was what our user was on).
this is complicated by the fact that I am now running installer vsn 2.0, whereas the user was running 1.2, and at the moment I don't have access to a WIN98 machine with 1.2 installer due to people being on holiday.
Interestingly, the (failed) log file reports MSI © (29:61): "Found shell folder G:\My Pictures by spelunking through the registry." - but then fails at CostFinalize when it cannot resolve a directory reference to g: Does this mean anything to you?
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 26 November 2001 - 16:13
Removing any directory table entries that are not actually being used in your setup should not cause any problems, but I've seen reports that it fixed problems. I don't know if it would fix yours.
I can't remember to have ever seen "spelunking through the registry" in a MSI log file.
lawrence_dan
-
- Members
- 1 posts
Posted 20 March 2002 - 00:40
Hello Ian-
I noticed your post regarding WIS Error 2103: unable to resolve path to shell folder. I know it was a few months ago but I was wondering if you had made any progress. I'm getting this error also and I don't think that it's related to the erroneous entries in the directory table either. I can reproduce the error on any msi repackaged or otherwise--including good old Orca.msi.
We have a windows 2000 group policy which redirects the 'My Documents' folder to a network location. This folder redirection policy is using the %USERNAME% variable and points to \\server\share\%USERNAME%. It doesn't appear to matter whether the network location is accessible or not, the msi always fails.
Definitely seems like a bug to me.
Any help is greatly appreciated.
Thanks,
Dan Lawrence
p.s. Here's a bit of the verbose log:
_
MSI (s) (98:C8): Found shell folder by spelunking through the registry.
MSI (s) (98:C8): Note: 1: 2103 2: 26
DEBUG: Error 2103: Could not resolve path for shell folder 26.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2103. The arguments are: 26, ,
MSI (s) (98:C8): Product: Orca -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2103. The arguments are: 26, ,
_
I noticed your post regarding WIS Error 2103: unable to resolve path to shell folder. I know it was a few months ago but I was wondering if you had made any progress. I'm getting this error also and I don't think that it's related to the erroneous entries in the directory table either. I can reproduce the error on any msi repackaged or otherwise--including good old Orca.msi.
We have a windows 2000 group policy which redirects the 'My Documents' folder to a network location. This folder redirection policy is using the %USERNAME% variable and points to \\server\share\%USERNAME%. It doesn't appear to matter whether the network location is accessible or not, the msi always fails.
Definitely seems like a bug to me.
Any help is greatly appreciated.
Thanks,
Dan Lawrence
p.s. Here's a bit of the verbose log:
_
MSI (s) (98:C8): Found shell folder by spelunking through the registry.
MSI (s) (98:C8): Note: 1: 2103 2: 26
DEBUG: Error 2103: Could not resolve path for shell folder 26.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2103. The arguments are: 26, ,
MSI (s) (98:C8): Product: Orca -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2103. The arguments are: 26, ,
_