How can I figure out where the Windows XP SUA ksh .profile file is on a system where I was not the person who installed it? (I'm searching google for the answer, but the combinations of ksh, windows XP, and profile lead to many, many hits that I am still digging through.) It is NOT in my user directory, so it is probably the system default .profile that I need to find?
Problem, if it has any bearing: The path is radically different before and after I start the ksh, and after the ksh starts it includes some contextually bad paths.
All I really want is to keep the path set up in the cmd.com batch environment from before ksh is invoked, but I think I first need to figure out where the change is coming from.
It is apparently located at C:\Windows\SUA\etc\profile
Open the run dialog by hitting Windows-Key+R and type the following command followed by return:
explorer "%USERPROFILE%"
A Windows explorer window should appear showing the content of the current user profile folder. The file you are looking for may be there or in some subdir, especially inside ApplicationData or Local Settings\ApplicationData (note: I work on an Italian XP version and dir names are localized, thus I may have spelled them incorrectly).
Note that you may have to enable the visualization of hidden files, if that .profile file was saved with the hidden attribute set.
Otherwise you may also search in C:\Documents and Settings\All Users, which is the folder where all settings common to all the users are stored.
Related
I'm battling with cygwin for quite a while now.
I searched far and wide on how to make cygwin create Windows-style symbolic links.
I tried the following:
export CYGWIN="winsymlinks:native"
export CYGWIN="winsymlinks:nativestrict"
export CYGWIN="winsymlinks:lnk"
I also tried exporting w/o the quotes.
I also tried from both cygwin/x86 and cygwin/x64
For the life of me - I can't get the Windows native symlinks to work.
I'm working on Windows7/64bit; cygwin version 1.7.25.
I'd love to get a solution for this one.
Thank you.
I got the same problem. In my case, I used winsymlinks:nativestrict and received an error report saying: Operation is not permitted.
This is becase of Windows UAC and the terminal emulator not being started with elevated privileges. So I run Cygwin mintty as administrator (you can right click the shortcut and choose "Run as administrator" or set the mintty shortcut property: Advanced -> Run as Administrator). After that, everything just works perfectly.
I also battled with this one for a while on Windows 7 with Cygwin.
Everything I read seemed to say that it needed export CYGWIN="winsymlinks:native", but no luck for me.
Then I read this blog http://zzamboni.org/blog/making-cygwin-windows-and-emacs-understand-th/ which said that just "winsymlinks" was all you need. Tried that and it worked beautifully :)
Just use this environment variable.
export CYGWIN="winsymlinks"
Expect it to work with Windows 10 Creator update when you enable developer mode
Something to consider:
https://github.com/git-for-windows/git/wiki/Symbolic-Links
Symbolic links are only available on Windows Vista and later, most notably not on XP
You need the SeCreateSymbolicLinkPrivilege privilege, which is by default assigned only to Administrators and guarded by UAC, but can be assigned to other users or user groups (see below).
Symbolic links on remote filesystems are disabled by default (call fsutil behavior query SymlinkEvaluation to find out)
Symbolic links will only work on NTFS, not on FAT nor exFAT
Windows' symbolic links are typed: they need to know whether they point to a directory or to a file (for this reason, Git will update the type when it finds that it is wrong)
Many programs do not understand symbolic links
This is really just an annoyance, but I'd like to see if someone has solved it.
I really love and need to have the Windows power toy "command prompt here".
I installed it first day on the XP laptop my new client gave me.
It works well in All folders EXCEPT those under the control of Base Clear Case.
If I create a junction (symbolic link) to that folder, and navigate to that, it does show in the pop-up menu.
I am thinking the clear case registry entry is overriding the command prompt here,
but I don't need this enough to muck about in registry on my clients machine.
I have seen it working on snapshot views (which are really simple files/directories on the C: drive), but not on dynamic views (which are mounted directory on the device M:)
The ClearCase submenu shouldn't matter, except it doesn't show up on Windows64.
From technote swg1PK36107:
ClearCase is a 32-bit application, therefore, the ClearCase and Windows Explorer integration will only work in a 32-bit Windows Explorer.
Maybe that limitation might have a side-effect for your own "command prompt here" plugin?
Found an alternative method that seems to work using file associations.
These are set under Tools / Folder Options / File Types in windows Explorer.
Reference Method #3 in the following link:
http://www.petri.co.il/add_command_prompt_here_shortcut_to_windows_explorer.htm
Now on to find the next annoyance.
The application I am working with writes to the User\Application Data folder on XP and the AppData\Roaming folder on Vista. On one of the Vista machines the AppData\Roaming folder is not present. As a result some of the features of the application are not functioning.
Have any of you encountered such a scenario before? I am not sure what to do in this case. Can I create the AppData\Roaming folder?
Thanks
jbsp72
If you're hardcoding those paths, you should be using environment variables instead.
On the machine in question, open a command prompt (WinKey+R>cmd>Enter) and enter echo %appdata% and press Enter. It should return the application data path for the current user.
...oh, and to use environment variables, replace, for example c:\Program Files\MyProgram\data with %programfiles%\MyProgram\data
There are many lists of these available, on of which is at http://vistaonwindows.com/environment_variables.html
We have a program that the installer checks for the existence of a config file, and if it exists, it doesn't copy that file over (it assumes the user has modified their config file and wants to keep those modifications). Unfortunately, this is a pre-Vista application and it keeps the config file in Program Files. The problem is, if you manually wipe out the directory when it re-installs certain API still thinks that there is a directory there. VB6, for example, and its browse for file dialog sees the folder, however explorer, cmd shell, etc cannot see folder. Writing over the file still leaves the old file there (to some API's, but not to explorer) which cannot be removed except form within the Browse for File dialog.
What is going on with these Phantom folders, and how do we delete the file so that all API's see the same thing? Maybe it has something to do with TxF, or the indexer for search, but both the installer we use (InnoSetup) and parts of the application (the parts written in VB6) are seeing the old version of the file, and everything else sees the current version.
As Oskar Duveborn said, it's very likely that what you're seeing is Vista's virtualization behaviour.
When a machine has User Account Control (UAC) enabled, standard users and non-elevated programs aren't allowed to write to the Programs folder. Windows instead silently redirects files to the appropriate subfolder of %AppData%\Local\VirtualStore (for example, C:\Users\MyUser\AppData\Local\VirtualStore).
If you browse the real folder in Explorer, you'll see the 'Compatibility Files' toolbar button, which you can use to browse the virtual store instead.
Note that this is only compatibility behaviour from Windows - your program should write to its own subfolder of %AppData%.
For more information, see this TechNet Magazine article.
Dunno if I'm on the right track, but doesn't Vista virtualize %programfiles% for applications that tries to write to it or otherwise are flagged as "not going about this the right way"? (and hence moves it somewhere into the user part of the filesystem instead, without telling the legacy app about it - making it kinda transparent)..?
Virtual Store Redirected files are stored somewhere in %appdata% - you can also find out the location by checking the "Compability Files" option in Explorer when at the aliased location. You need to stop writing to %programfiles% to get rid of this behaviour as far as I know.
Do you mean the AppData folder (C:\Documents and Settings\UserName\AppData)? I'm not on my vista machine, but I think that's the path, and afaik it's not wiped after an uninstall.
The TechNet link by Ant above (accepted answer) is no longer valid. The new link is:
http://support.microsoft.com/kb/927387 - Common file and registry virtualization issues in Windows Vista
On OS from win 2000 or later (any language) can I assume that this path will always exists?
For example I know that on win xp in some languages the "Program Files" directory have a different name.
So is it true for the System32 folder?
Thanks.
Ohad.
You definitely cannot assume that: Windows could be installed on a different drive letter, or in a different directory. On a previous work PC Windows was installed in D:\WINNT, for example.
The short answer is to use the API call GetSystemDirectory(), which will return the path you are after.
The longer answer is to ask: do you really need to know this? If you're using it to copy files into the Windows directory, I'd suggest you ask if you really want to do this. Copying into the Windows directory is not encouraged, as you can mess up other applications very easily. If you're using the path to find DLLs, why not just rely on the OS to find the appropriate one without giving a path? If you're digging into bits of the OS files, consider: is that going to work in future? In general it's better to not explicitly poke around in the Windows directory if you want your program to work on future Windows versions.
No, you can't assume that.
Windows can be installed to a different path. One solution is to look for it by calling GetSystemDirectory (implemented as part of the Windows API).
Windows can be installed on a different harddrive and or in a different folder. Use the %windir% or %systemroot% environment variables to get you to the windows folder and append system32. Or use the %path% variable, it's usually the first entrance and the preferred method of searching for files such as dlls AFAIK. As per comments: don't rely too much on the system32 dir being the first item. I do think it's safe to assume it's in %path% somewhere though.
I would use the GetWindowsDirectory Win32 API to get the current Windows directory, append System32 to it an then check if it exists.
It might be safer to use the "windir" environment variable and then append the "System32" to the end of that path. Sometimes windows could be under a different folder or different drive so "windir" will tell you where it is.
As far as i know, the system32 folder should always exist under the windows folder.
Just an FYI, but in a Terminal Server environment (ie, Citrix), GetWindowsDirectory() may return a unique path for a remote user.
link text
As more and more companies use virtualized desktops, developers need to keep this in mind.