testand returns fail path in windows7

[dug9000]

For the path you are passing to excel, are you sure that all of the intermediate directories exist? Perhaps the error is because one of the intermediate directories does not exist rather than because the path is not localized. My understanding is that the APIs that most programs use internally expects the non-localized path names (i.e. "Program Files" rather than "Program") so it seems odd that excel would fail because of having the non-localized paths.

Have you tried adding code that replaces "Program Files" with "Program"? If not you might want to try it and if excel still gives you an error then you will know that that is not the cause of the error. If excel does not give you an error when you make this string replacement then perhaps it is expecting the localized version (which is very odd since it seems like it is not easy for programs to get that and no programs written before Vista existed will even know about the possibility of having to localize the path name).

From what I have read in blogs the localized path name on Windows Vista and Windows 7 is purely cosmetic and most programs should still be using the non-localized version internally, the localized version is only for display purposes when displaying the path name to the user (for example in File Explorer or the open file dialog box).

Most likely the cause of the error you are seeing is due to something other than TestStand using the non-localized paths, such as intermediate directories not existing or the path not being specified correctly in some other way. Replacing "Program Files" with "Program" as an experiment will help you verify this.

Hope this helps,

-Doug

[dug9000]

Just want to add that the paths TestStand is giving you with "Program Files" in them are the ones gotten from the Windows OS and must be working fine with the Windows SDK APIs or those files would not have been loaded successfully. This is yet another reason why I think the cause of the error you are seeing is unrelated to path localization.

-Doug

[TSJim]

This could also be a UAC issue with Windows 7.  If TestStand is launched in a user account it doesn't have privileges to write to the 'C:\Program Files' or 'C:\Program' folder.  From the JPG it looks like TS is interacting with Excel and saving information - could you provide a simple sequence with that step included?  What version of Office are you using?  There are some simple workarounds if this is the case.

Thanks,
Jim

[AllenP]

My basic Swedish skills tell me that the error message says something about access to the file being denied, so I think Jim could be correct that UAC is the problem.

[Petri]

Unfortunately I have not had much time today to look into this.

Excel is in Office version 2003.

Error message says that filename or path doesn't exist.

The sequence file, which generates the excel report, first opens an excel template file and afterwards tries to save it with save as function. I tested manually do the same thing; open the template file and save as it in same folder. Excel complained that the folder is write protected. If I move files in windows explorer between folders in c:\program\ I am asked to have administrator rights. 

I verified user has administrator rights, logged out and logged in again -> same problem. I check the properties of the folder in windows explorer. According to windows explorer folder is write protected. If I disable write protection and accept it with OK button, next time I open the properties window the write protection is enabled. Is it so that write protection to folders in c:\program\ cannot be disabled ?

My first feeling for the problem was to rely Excel API error message. But perhaps it is something to do with the rights in win7. User has administrator rights and cannot move files in subfolders in c:\program\. Excel cannot save files in subfolder in c:\program\. Can somebody help to tell me if these restrictions can be disabled ?

regards,

petri

[dug9000]

As of Windows Vista and higher Microsoft recommends no longer allowing write access to directories under program files (This helps protect against viruses and malicious programs by keeping them from being able to modify and spread to programs installed under program files). The OS probably does not allow removing protection from the program files directory itself, however I think it does allow adding write permission to subdirectories which you create under the program files directory. However, my recommendation would be to not use the program files directory at all and instead use either "C:\Users\Public\Documents" or "C:\ProgramData". This is the new standard for Windows OSes going forward.

Hope this helps,

-Doug

[TSJim]

If you do want to grant access to the program folder - the following command can be run from the command prompt launched as Administrator:

icacls "C:\Program Files\yourpath" /grant useraccount:(OI)(CI)M

of course change 'yourpath' and 'useraccount' in the command line.

As Doug stated, it is a little risky as far as malware and viruses are concerned.

Thanks,
Jim

ps - my browser interprets 😞 as a sad robot - it should be a colon ':' and right parenthesis '(' without a space : (

[Petri · Accepted solution]

thanks for hints and support. I understand the risks with allowing writing to system folders. I couldn't success with icacls command - permission denied for the inlogged user. also takeown command says permission denied. For future proof system I think it is better to adapt this new folder structure.   

I use the TS deployment tool to build installation files and in that case I need to add a folder to workspace where executing sequence file in deployment station can store reports. For that purpose I have defined a subfolder to program installation directory which now in latest OS versions is difficult to use. To define an another directory, an ideal case would be to have same path independently of OS version (XP, Vista or Win7) so that operators can find the reports easily. When I look into the deployment tool, it seems to be difficult to add e.g. "My Documents" to workspace because it is user dependent (I can't add that user's "my documents" folder to workspace who has logged in to the deployment computer.) An acceptable solution would have been to have in deployment tool a destination directory "My Documents" which will be created to that user who installed the software. My work around is to use the personal directory as destination and a subfolder in c:\.

Best Regards,

Petri

[dug9000]

You have to run the commmand prompt "as Administrator" in order to have permission to run icacls on the directories. Find the Command Prompt shortcut in the start menu under accessories, right-click on it, and select "Run as Administrator" from the menu.

As far as where to install user editable things with the deployment utility, I recommend you install to either the "TestStand Public" directory (which will show up in the user's My Documents folder under "National Instruments\TestStand <version>" for all users on the machine), or to the "Personal Directory" (which will also show up in the My Documents folder, but not under National Instruments, instead at the top level, and only for the user that actually installs the deployment).

Hope this helps,

-Doug

[Petri]

I succeeded to use the icacls command. But Excel is still unable to save files in subfolder in c:\program. I even contacted our IT department and they verified that this is the case when using another user than administator.

I have not (yet) tested deployment with personal directory leaving the directory path unspecified. Thanks for that hint, perhaps I will test it later to get the reports only to that user's "my documents" who has logged in.

Best Regards,

Petri