Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

GETENV() Buggy on Win8 or Configuration Error?

Status
Not open for further replies.

Olaf Doschke

Programmer
Oct 13, 2004
14,847
DE
On my own Windows8 PC VFPs GETENV("TEMP") results in C:\Users\username\AppData\Local\Temp, where username is your windows account name, actually another environemnt variable %USERNAME%. This has been that way since Vista.

This can be configured differently in System Environment Variables, anyway GETENV("TEMP") should give an existing temp folder, but at a customer I get an error message about not finding a file in C:\Users\username\AppData\Local\Temp\6
The Temp Folder is stored in a Configuration Object as a property and that property is only written once at startup with ADDBS(GETENV("TEMP")) and nothing else is done to that Property, but reading it. So the 6 is not appende by my code, it must come from the system environment variable.

I may later get hands on some Windows8 client with the problem, but for now the question to you, what you get from GETENV("TEMP") if you already work under Win8, is there maybe a bug in VFP? I can't really imagine and guess this simply is a configuration error.

Bye, Olaf.

 
I don't have a Win 8 machine with the VFP development environment to hand, so I can't check this just now. But, just out of interest, what do you get with SYS(2023)? Or with the GetTempPath() API function?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
?GETENV("TEMP")

or

?sys(2023)

I get the same response for both in Windows 8

C:\USERS\MIKE\APPDATA\LOCAL\TEMP



Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
 
You could try command prompt and type 'set', it will list all environment variables.
then compare your environment variables with vfp genenv("varname").
Possibly user name change in Win 8 could have caused it.
 
On my Windows 8* installation, I get C:\Users\%USERNAME%\AppData\Local\Temp and I think that's the default.

There may be a difference when a machine is a member of a domain, and I think roaming profiles can make a difference as well.

But if you're getting errors that the location just doesn't exist I suspect the user (or his system administrator) has engaged in some creative misconfiguration.

*Note that my Win8 "machine" is Windows 8.1 running in a Parallels VM on a Mac. Shouldn't make a difference. It doesn't *know* it's on a Mac. But wanted to include that caveat. [glasses]
 
It actually turns out it's not a win8 thing. The story in short is: A Win8 rollout made some software unsuable, not because of Windows incompatibility, but due to introduction of a whitelist of allowed software, which was introduced by the IT department. Some product owners were sleeping and not adding their application to this whitelist.

As the application didn't run due to not be in the whitelist, a workaround was to use VMs via Remote Desktop, which exist for Home Office workers and the %TEMP% variation comes from there. Even though different users on TS sessions on the same machine already have different temp folders, this is varied. These VMs are not having Win8 or any other Windows Client OS, but 2008 Server. I don't know, but it might be quite normal to have such variations.

I said "not finding a file in", I just assumed that's because of the additional /6/, but indeed a xcopy failed to copy something into %TEMP% and that's on top of all the other things.

You know why bits are a unit of information in information science. You only get informations bitwise.

Bye, Olaf.

 
I now had hands on such a server and results are a bit puzzling.

The Environment variables %TEMP% and %TMP% as can be seen in Control Panel/System...Environment Variables are defined as %USERPROFILE%\AppData\Local\Temp.

VFPs GETENV("TMP"), GETENV("TEMP") and also SYS(2023) all give the extra subfolder \6\ or \2\ or whatever number, which also exists. The number may be a terminal Server session id or something like that, in case the same Windows user uses two sessions, he would still have two different temp folders. Maybe that's the reason, but it doesn't seem to come from Windows.

Bye, Olaf.
 
I just tried it on a remote desktop session to a server 2008 R2 machine and the temp folder ended in /2/

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you.
 
That's interesting. I just tested an RDP connection to Windows 7 and WinXP (yeah, don't ask) and don't see anything like this. (Don't have Win8 on RDP yet.) It must be post-Win7.
 
Out of curiosity, is this with RDP into a terminal server or RDP into a single workstation?
 
Mine?
It's a Server 2008 R2 server, not a full TS

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you.
 
It's a more complicated situation, in the end I'm using remote desktop (mstsc) to a single VM, but the environment is a) first connecting to a VPN and then logging in to a VM server. I'm not into the details, but my direct peer contact at the company always tells, they pay the it department TS licenses, so I think this is a VM being hosted on or as part of Terminal Servers/Services.

The VMs in question use a Win2008 server OS. They are just used as a workaround for the Win8 clients are shrinked down to a whitelist of allowed software, which wasn't including the apps not working now, So win8 really isn't involved, that's only what I thought initially. Instead they use the apps on a win2008 vm now. So it may be a server OS feature, too. Yet only VFP does this, the OS itself does not append some number folder. Griffs test also points to Win2008. What I didn't test is simply Echo %TEMP% and %TMP% at a cmd.exe shell window, then perhaps we'll see it's rather an OS feature.

Bye, Olaf.
 
The answer for extended path is here:

My assumptions are correct, it has to do with TS. Even though different users already have separate temp folders, as they are part of their %USERPROFILE%, it's really made to keep sessions apart from each other.

Actually it's good, as we use it for that reason. It's also not the cause of the problems we had. I still don't know yet what problems arose in win8 really, all the error messages I got were not from Win8, as it seems, the only message that could have come from there was a message about the application being forbidden, because not being white listed.

the file not found in %TEMP% was not found, as XCOPY failed to copy it. "Share violation" can be seen, if you concentrate on the shell window. Which is even more puzzling, as the temp folder is not only per user, but even per session. So it rather has to be a share violation of the source folder than the destination folder. Nobody is using files fro the source folder, though. Now don't ask me why there is a bunch of files always copied to a local temp folder at each start. I'm not into all the details, just inherited all this a month ago or so and didn't really have much time digging into it.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top