I am using a batch file to prevent the UA prompt from showing up to install programs:
set __COMPAT_LAYER=RunAsInvoker
But recently I have noticed that more and more installers throw errors like:
Error opening files for writing: https://...
I have tested running the same installation file entering the admin password (so without using the batch file) and it works perfectly fine.
Why do such errors occur, what has it to do with the environment variable mentioned above, and is there a way to fix it? Thanks in advance.
Related
I have a windows10 machine using Remote-SSH to interface with repo on an Ubuntu18.04 system.
Until about a month ago I was able to open files using VS Code's integrated terminal.
Now entering code ./myFile.txt returns immediately. No error, no file opened.
If a non existent file is opened code ./myNonExistentFile.txt the same thing happens.
Running code ./myFile.txt into an entirely local setup (no Remote-SSH) works; the file opens in VS Code.
Remote-SSH is otherwise working.
Has anybody else noticed this behavior?
#Max Lobur may be right. If not, you still feel free to restart the VS Code.
It's expected. You probably don't have vs-code on a remote machine, nor have forwarded the X-server thus nothing will happen when you run this.
I suggest mounting the remote file system to local machine and run code . locally: https://www.digitalocean.com/community/tutorials/how-to-use-sshfs-to-mount-remote-file-systems-over-ssh
As a last resort, try deleting your server's .vscode-server folder, which is located at your home folder, as detailed in https://github.com/microsoft/vscode-remote-release/issues/1443
I have mounted a Windows file share in CentOs 8. I am mounting the drive by adding the following line to the /etc/fstab file:
//myservername/foldername /mount/test_share cifs user,uid=1000,rw,nocase,iocharset=utf16,suid,credentials=alocation/share_secret 0 0
I have tried both utf8 and utf16 as the iocharset.
There is a file in one of the fileshare folders with emojis in the name.
Unfortunately I get an "Invalid Argument" error whenever I try to do anything with the file. An ls-i command shows it as a messed up inode. See image.
Any ideas on how I could mount the windows file share to cater for this or any other work around?
BDH, Hope you are well.
A way forward here is to install a font that will render the unicode.
For me it was yum install fonts-noto-color-emoji and a reset of the terminal with fc-cache -vf
You can imagine my excitement when I found this post! I can also imagine you are in a place now where you care less about the answer.
See you round mate
So, just in case anyone else runs into this. The problem seems to have been specifying "rw" explicitly instead of allowing Samba and Active Directory to do their things in the background. It only manifested with filenames containing emojis for some reason I never figured out. The following mount worked:
//myservername/foldername /mount/test_share cifs user,uid=1000,suid,credentials=alocation/share_secret 0 0
I've been working on trying to figure out why our auto-generated deploy.cmdscripts will not work when installed to C:\Program Files (x86)\OurProgram. I finally narrowed down the issue to the closing parenthesis in (x86) as the script would terminate with "Files was unexpected at this time". One possible solution was to manually create another batch file to set _DeploySetParametersFile to a Windows path ( C:\Program^ Files^ (x86^)\OurProgram\Program.Parameters.xml). This isn't a valid solution for me, so I dug into the auto generated file and found the issue to be 2 variables:
RootPath
_DeploySetParametersFile
Both of which were referenced using %'s(i.e. %RootPath%), however as soon as they were changed to !'s(i.e. !RootPath!), no 2nd script was needed and I can run the cmd script from Program Files (x86) just fine. The issue of course with this is, the deploy.cmd file is auto-generated on each build, thus I have to change it for each build I do. My question is this: Is there a way to edit the template Visual Studio uses to generate the deploy.cmd file? If so, where? It seems so ridiculous that Microsoft would have this be an issue in their web deployment.
To run tests in Jenkins I use the next batch command:
"C:\Program Files (x86)\NUnit 2.6.4\bin\nunit-console.exe" /result:TestResult.xml "C:\Users\Denis\Documents\Visual Studio 2013\Projects\MyProject\App.nunit"
Here how it looks in Jenkis:
The problem is: it doesn't generate TestResult.xml file!
When I run the same command as a .bat file from my desctop it creates the TestResult.xml file.
Any ideas what is wrong with Jenkins?
P.S. I searched for created file in all possible folders and even via "search"
I came up with thought that the file is generated and removed then or something like this.
The thing is that I don't see this file indeed but Jenkins generated report based on this file! So I think maybe after generating report the file was removed automatically.
I had faced the same issue and I found the test results xml file under my user directory in Win 7.
Note : I think it's some problem with nunit that it doesn't export the file to the location of which we provide the path.
I'm getting errors when I attempt to run my project deployed to app engine. I see issues like:
java.lang.ClassNotFoundException: com.seattleglassware.AuthServletSupport$$anonfun$finishOAuth2Dance$1$$anonfun$apply$33$$anonfun$apply$34$$anonfun$apply$37$$anonfun$apply$40$$anonfun$apply$41$$anonfun$apply$42$$anonfun$apply$45$$anonfun$apply$47$$anonfun$apply$48$$anonfun$apply$49
The class name looks reasonable (well, for certain values of reasonable - this is code generated by the Scala compiler). I see the file in my local web/WEB-INF/classes/com directory and I can decompile it with javap (so I don't think it's corrupt or anything silly like that.) Everything works fine running on a local debug server.
Even more strange, I can pour all the .class files in web/WEB-INF/classes into a jar file like this:
cd to the web/WEB-INF/classes directory
jar cf ../lib/classes.jar .
And now, if I upload the project (pressing the deploy button in Eclipse), I don't see those ClassNotFoundException errors. Delete the jar file, re-upload the project, get the errors again.
I'm wondering if there's some sort of limit on the names of .class files? Or something else happening in the deployment process that's causing this to happen?
EDIT: running from the command line made this much more clear (using maven now):
SEVERE: Invalid character in filename: WEB-INF/classes/com/seattleglassware/AuthServletSupport$$anonfun$finishOAuth2Dance$1$$anonfun$apply$33$$anonfun$apply$34$$anonfun$apply$37$$anonfun$apply$40$$anonfun$apply$41$$anonfun$apply$42$$anonfun$apply$45$$anonfun$apply$47$$anonfun$apply$48$$anonfun$apply$49.class
But it still looks to me like that's a valid filename.
The inclusion of "special" characters in the file name may be the issue here.
There is currently an open issue regarding "special" characters in project file names.
Issue 2211: Special characters are not supported in the filenames in the project
The original issue was reported by a Python App Engine user, however if you look in the comments you'll see that it apparently affects Java users as well.