Vista Install Issue with DOpus9

During the install of DOpus9, the installation aborts with this dialog:

Component transfer error

Component: Program Files
File Group: DOpusData-Lang
File: <MyCSIDL_COMMON_APPDATA>
Error: The filename, directory name, or volume label syntax is incorrect


Looks like it's an issue with the installer. Does anybody have ideas?

Given how many people it's worked fine for try re-downloading the installer from the gpsoftware site. Perhaps your copy has been corrupted in some way.

We've seen just one instance of this before and it was that the Vista OS has not been installed correctly. (Somehow!)

What you are seeing is the InstallShield installer for Opus not being able to create a normal folder in the system Common Data area. The install script looks in the registry for the standard application data path defined by

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellFolders\Common AppData

On a normal Vista machine, this should be C:\ProgramData.

I suspect on your machine it is set to a non-existent path or perhaps the old XP path of C:\Documents and Settings\All Users\Application Data. We've see one user's machine where this was so. In Vista, 'C:\Documents and Settings' aren't used anymore. His solution was to edit this entry for Common AppData entry pointing to C:\ProgramData. After he reported that Opus installed fine.

You need to discuss this with the installer of your OS. There could be other serious issues with your install of Vista somehow.

I encountered this same problem, on a newly purchased and clean Vista Business preinstalled on a Sony VAIO machine. Seems to me that either GPSoftware should go tell Sony that their machines are somehow "non-standard" ---- else they should find a work around.

It could be that this key isn't created until something is run post-installation; I tried installing DOpus 9 relatively soon after firing up this new machine.

It's not our problem if the machine is not set up properly. The correct Microsoft defined default application folders should be set up corerctly. If they are not then the OS is incorrectly installed and you need to talk to the supplier. So you should report the problem to Sony.

ElephantHunter, if you open a command prompt and then run the program in the attached zip, does it print a directory location (like C:\ProgramData) or does it display an error message?

The program just calls the SHGetFolderPath API. I thought it was worth checking whether the API works on your system even if the registry value isn't found. Let us know the result.

HRESULT hr = ::SHGetFolderPath(NULL, CSIDL_COMMON_APPDATA, NULL, SHGFP_TYPE_CURRENT, szPath);


FindCommonAppData.zip (26 KB)

I tried (1) renaming the key (Common AppData) to something else, and (2) changing the value to something obscure. In both cases, when I run your FindCommonAppData app, it still manages to display C:\ProgramData (on my Sony VAIO w Business Vista.) Yet the DOpus installer failed, as reported above.

It looks like the OS caches the registry values so if they were there and you changed/removed them then I don't think it would have tested much.

I guess rebooting after changing the registry would test it, although I haven't tried that yet myself.

(I was hoping someone could run the test program on an untouched machine that still had a machine with the Opus installer.)

[quote="nudel"]ElephantHunter, if you open a command prompt and then run the program in the attached zip, does it print a directory location (like C:\ProgramData) or does it display an error message?

The program just calls the SHGetFolderPath API. I thought it was worth checking whether the API works on your system even if the registry value isn't found. Let us know the result.

HRESULT hr = ::SHGetFolderPath(NULL, CSIDL_COMMON_APPDATA, NULL, SHGFP_TYPE_CURRENT, szPath);[/quote]

I had the same issue. Tried your program and it returns C:\ProgramData just fine. However looking at the registry entry that Greg said I found that there was no entry there at all for it. Created it manually and DOpus installed fine.

I've updated the install script to use the SHGetFolderPath function so this issue should be resolved in version 9008.