Our customer complains that their taskbar is hidden once they connect to the application through Citrix.
I tried to found out some solutions online but couldn't get much information apart from checking taskbar configuration.
Could someone help how to get rid out of this?
Thanks in advance
Sounds like and issue with seamless flags
https://support.citrix.com/article/CTX101644
Also, check your windows build. Make sure you don't remove the short name (it was a security issue sometime back) for the programs files folders. In CMD, go to the root of C and type DIR /x
Should look like
12/30/2016 05:36 AM PROGRA~1 Program Files
02/24/2017 05:18 AM PROGRA~2 Program Files (x86)
Related
I am not able to find checkout option for a file when I right click on it in ClearCase explorer while the option is available for rest of the files.
The only difference is that the file I want to check in has a very long name ( I am using Windows ).
While I am able to check in via cleartool commands, it isn't possible from front end ( CC explorer) Is there any way to check out such files from CC explorer?
There are two possible causes for a checkout unavailable:
the path of the file itself is too long (combined with the long filename, more than 256 characters): a subst command can help shorten the path.
or the file is already checked out.
A cleartool status can help distinguish between those two cases.
And a cleartool lsvtree -graph aFile (replace aFile with your long filename) can help see the file history and see if it is checked out (reserved or not) in another view.
The window 255 characters restriction for file name can't be bypass or any sidestep if it.
You have the following options:
1. Try to shorten the name. Including all the folders that are the prefix for the view. Like vonC suggested.
2. Try create the view on Linux, and mount the folder to some shared area that can be seen in windows.
3. Use dynamic view, but Im not sure it will work.
Keep in mind, that other apps can also fail even after you solve it for clearcase as it is a Windows problem. Like msbuild or visual studio.
Is there a good technical or other reason why the MS hard-coded the Documents folder as the default location for WindowsPowerShell? MS has been criticized for too much configuration over convention in the past (WCF?), but a case can be made for more configuration in PowerShell. I, and I presume most developers, like to keep their development work centralized in a separate folder or volume away from personal and system files.
For instance, if you install PoshGit, it will install itself in C:\Users\Your Name\WindowsPowerShell\Modules. I don't want it to install itself there but in my own development partition d:\Dev\PowerShellScripts. There's no environment variable that controls this location.
Is there a reason for this or I just don't get it?
Can you explain yourself a bit more.
According to my understanding PowerShell.exe interpreter base directory is the one defined by $env:HOMEDRIVE, $env:HOMEPATH, that can be change using the user profile.
As shown in the screen shots here under :
Edited :
Ok, the screenshot comes from the user property in Active Directory MMC, you've got a simplest one in your windows seven user properties. But this has nothing to do with your problem.
Your problem is around the module installation. The think that you have to know is that Modules can be installed quite everywhere (even on a shared directory with some tricks). By default the environnement variable $env:PSModulePath points to the paths where Get-Module -ListAvailable look for them. So you can add d:\Dev\PowerShellScripts\Modules in this path and then copy the subfolder of C:\Users\Your Name\WindowsPowerShell\Modules created by PoshGit inside your Modules directory and it should work. Modules as opposite to Snapins don't need to be registered.
Now the reason why PoshGit choose to put module in user profile, raser than let you choose the place is PoshGit installer problem.
For more explanations read about Modules and about_environment_variables.
I try to install/run emacs on a Win7 64-bit machine after using it for years on a WinXP 32-bit machine and run into a problem I do not find any help for in the documentation or on the web.
Symptom:
when starting runemacs.exe for the first time it creates the file
*C:\Users\USER\My Documents.emacs.d*
as one would expect (for my administrator as well as for my user account)
and comes up operational
from the second start of runemacs.exe it breaks in the startup phase,
displaying the scratch buffer, ringing the warning bell and displaying in
bottom line the error:
File exists: c:/Users/USER/My Documents/.emacs.d/
buffer messages specifies:
make-directory: File exists: c:/Users/USER/My Documents/.emacs.d/
if runemacs was called with a file to open, i.e. because the file type was
associated with it and the file was opened to edit, the file is not open
and ready to be edited, but a file can be opened via the menu File->Open File...
but my configurations in the file
C:\Users\USER\My Documents.emacs
are not loaded
My goal:
I want to regain the way I used emacs on the old WinXP 32-bit system:
click a file associated with emacs, get it opened and ready for editing, get my configurations in .emacs loaded automatically, i.e. work with emacs seamlessly.
Checks done and failed attempts to fix this:
I tried the following newly downloded versions of emacs
emacs-23.4-bin-i386.zip
emacs-23.2-bin-i386.zip (the one I used on the WinXP)
I had the emacs directory containing the directory stucture (bin, etc, ...)
located at:
C:\Program Files (x86)\emacs-23.4\ (my preferred location)
C:\Emacs\emacs-23.4\
in the download directory, where I originally extracted it
My HOME variable points to:
C:\Users\USER\My Documents (default)
C:\Users\USER\My Documents\ (tried)
My PATH variable contains:
C:\Program Files (x86)\emacs-23.4\bin (default)
or the corresponding other locations which I tried
The ownership and permissions of my C:\Users\USER\My Documents.emacs.d
look OK:
owner is the USER (administrator or standard_user)
permissions grant Full Control
Having originally installed emacs to *C:\Program Files (x86)\emacs-23.4*
using the administrator account, I also tried to use user account installation
instead (to check for some non- obvious parameter/access permission not set
right if the admin account is uses for setup)
For the runemacs.exe executable I manually set the compatibility settings to
Windows XP (Service Pack 3)
default setting after unpacking: no compatibility setting enabled
I removed the private configuration file C:\Users\USER\My Documents.emacs
(inherited from my XP installation) to check whether it produces a screw-up
All that did not change a bit of the described symptom, i.e. either I screwed up
in testing the above and missed a particular setting which should work, or I am looking into the wrong direction...
It is still unclear to me whether this has anything to do with:
W7 64-bit vs. XP 32-bit
environmental parameter screw-up
emacs configuration (.emacs, .emacs.d) screw-up
general stupidity (of me ;-)
... and why is it has emacs a problem with it in the first place, that the .emacs.d directory already exists... That should be the standard case...
Any help and wisdom much appreciated.
First of all, nice question. The details and listing of what you've already tried is helpful.
Some points:
Don't have spaces in key paths (Emacs, and %HOME%). Generally, things work
fine. But when things break it's often hard to debug and trace back to the
fact that some package author didn't take spaces properly into account.
Set a HOME environment variable to your %USER_PROFILE%. Make it
%USER_PROFILE%/home if you must, but I use the former.
Start by running emacs without any customization.
runemacs -Q
When that works, add your customizations one at a time.
n.b. This answer is not relevant to the original question (which was about Windows), but may be useful to Unix users searching for this error message
You will get this error also if emacs does not have the correct permissions on the .emacs.d directory.
Check it
ls -ld $HOME/.emacs.d
And make sure the user you are running under has rwx permissions!
I got similar problems when I installed the new version of emacs on a new installation of the ubuntu 12.10. I get the problem fixed by chmod 777 .emacs.d, that is, as the previous post pointed out, the emacs does not have the access right to .emacs.d directory. Hope this help.
I just wasted an hour or so chasing this. I was able to resolve it but putting it in q/a form hoping others might benefit.
The symptom was that I could not access a directory. I could browse to it in explorer or command window. I could not even see its security permissions in properties window.
The folder is created by our build process, which meant I could pretty much do no work. Searching on net was no help.
Answer below.
It turns out it has to do with how cygwin does not lock a directory. The build process removed the directory (rmdir /s u:\target) and then recreated it (mkdir u:\target). I had a bash window where that directory was the current directory.
When the build process (bat file) called rmdir it succeeded, even %errorlevel% was 0. However the subsequent mkdir failed with Access is denied.. The build process unfortunately checked only for rmdir failure, not mkdir.
Thanks to handle.exe I found the folder to be in use by bash.exe, From there it was straightforward. Changing the current directory finally deleted the folder and another go at build set everything right.
I realize this is unix behavior to remove a file only after all handled to it are closed, but its simulation in windows is somewhat non-intuitive.
i need to install some file to C:\Documents and Settings\currentUser\SomeFolder.
I can't find some buildin function/variable for it.
Can someone help/tell me the <DirectoryRef Id="TARGETDIR"> structure or the solution for my problem?
Thanks.
First, are you sure that you want to do this? You will get a behavior where each user who logs in and starts up your program will attempt to do a repair and ask for the original install if not found. Also when you uninstall you won't be able to clean up all the users profiles.
Many people prefer the "first run" pattern where you have the installer install to C:\Documents and Settings\All Users\ and when you run your program it copies the files to the current user profile if needed ( usually only if you are overriding something that is set for all users ).
Otherwise, here is a list of available directories in Windows Installer / WiX
System Folder Properties:
http://msdn.microsoft.com/en-us/library/aa370905(v=VS.85).aspx#system_folder_properties
You'll want to choose from AppDataFolder, LocalAppDataFolder and CommonAppDataFolder.