I am trying to read .txt file in Maui Program from the location which I am getting from
Path.GetPathRoot(System.Environment.GetFolderPath(System.Environment.SpecialFolder.Personal));
I am getting access denied error.
What permissions have to give to the windows application.
Reading system root files requires administrator privileges
Run Visual Studio as administrator.
In solution explorer, add new item, select "Application Manifest File".
change
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
to
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Related
I have a file with description "Подключаемый модуль пересылки событий WS-Management" and name dhcpsapi.exe running in task manager. It seems like a virus to me.Whenever i tried to delete or open its location i am getting access denied in my admin account.Tried to delete it from cmd-Administrator but keep getting the error 'Access Denied'.
I can't see its folder in file explorer or in hidden files but can see it in command prompt (dir /a).
I need to access this folder and delete it. How do i access it from command prompt or from windows explorer.
Screenshot of file properties
Resolved. I unchecked hide protected items from folder options. Then gave permission to User but it was still inaccessible and windows defender scanned that folder and identified it as a trojan virus and removed the process from task manager. Then i deleted that folder with a software 'unlocker' from drive and recycle bin.
Screenshot of file details
I've inherited a project that uses WIX Toolset (3.10.3) to build the installation package. The application downloads and stores shared data in c:\ProgramData\Vendor\ApplicationName. This path is however not created during the installation, but rather during the execution of the application itself, whenever the path is requested for the first time.
I've now discovered a permissions related problem that occurs when multiple Windows users uses the application. Whenever the application downloads new data files from back-end, it's the current windows user that gets "Full control" permissions for those files. When someone else logs in with another Windows account, they only have read permissions to those files. And these mixed permissions causes problems when the application tries to keep the local files synchronized with back-end.
Since the application doesn't require elevated priviliges, I have to correct this during the installation. As a first step, I've now made sure that the c:\ProgramData\Vendor\ folder is created during installation, and that it gets correct permissions with <util:PermissionEx User="Everyone" GenericAll="yes" />. Since these permissions are inherited, it will solve the problem for all users doing a fresh install.
The problem is that the permissions are only inherited by folders/files created after the installation. This means that users who upgrades from a previous version will still have data files left with mixed permissions. I therefore need to make sure that all existing folders and files gets the new permissions during installation. How do I accomplish this?
Ok, this is how I solved it. Hope it can help someone else in the future.
First, I added the following things to the wxs file for the MSI:
<Directory Id="CommonAppDataFolder">
<Directory Id="ProgramDataVendorFolder" Name="MyVendor">
<!--This will create the \ProgramData\MyVendor\MyProductName\ folder. -->
<Directory Id="ProgramDataAppFolder" Name="MyProductName" />
</Directory>
</Directory>
<DirectoryRef Id="ProgramDataAppFolder">
<Component Id="CmpCreateCommonAppDataFolderWithPermissions" Guid="13ae94b7-9ef5-4181-bfa9-933844a13418" Permanent="yes">
<CreateFolder>
<!--This will ensure that everyone gets full permissions to the folder that we create in the ProgramData folder. -->
<util:PermissionEx User="Everyone" GenericAll="yes" />
</CreateFolder>
</Component>
</DirectoryRef>
And then included it:
<Feature Id="ProductFeature" Title="$(var.ProductName)" Level="1">
<!--Add folder -->
<ComponentRef Id="CmpCreateCommonAppDataFolderWithPermissions" />
</Feature>
These three things made sure that all users had full access to the folder in ProgramData, even if the folder already exists.
But changing the permissions will not be enough, if file virtualisation is already active due to previous permissions problems. To turn off file virtualisation, I added an app.manifest to my executable with:
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
Keep in mind that if the previously used VirtualStore contains files that are important, they will not automatically appear in the ProgramData folder.
More info regarding file/registry virtualization can be found here: https://blogs.technet.microsoft.com/mrsnrub/2010/08/11/uac-virtualization-allowing-standard-users-to-update-a-system-protected-area/
My application (written in Visual C++ 2008) saves a file with extension .xxx (for example). If I right-click on a file with that extension, select "Open with", and then select my application, any programmatic writing to a file inside my application to a temp directory or even to the directory of the file I opened gets redirected automatically (I assume by Windows) to C:\windows\system32. This behavior does not occur when the file is opened inside the application using File > Open or by double-clicking on the file. This redirection to system32 probably started when I switched from Visual C++ 6.0 or with Windows 7, I don't know which. The program has been successfully running for 13 years. I tried to capture in code the current working directory after opening the file via "Open with" by extracting the directory path of the file but it is annoyingly changed to C:\windows\system32. Even the path obtained from GetTempPath is changed to C:\windows\system32. I am assuming Windows security is causing this to happen. Does anyone know anything about this.
Please read carefully the documentation of the GetTempPath function
The path specified by the TMP environment variable.
The path specified by the TEMP environment variable.
The path specified by the USERPROFILE environment variable.
The Windows directory
So there is a change, that the windows directory gets selected as temp path...
Also, please verify that your application has a valid Vista manifest! If this is not existend, then several redirections and virtualisation will happen with your application:
<?xmlversion="1.0" encoding="utf-8" ?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Or are you talking about the current working directory? The current working directory is mostly "%SYSTEMROOT%\system32 for shell-starting...
I have an Inno Setup installer that worked fine on my machine (Win 7 32-bit), but did not work at all on a test machine (also Win 7 32-bit). After some investigation, I found that the reason is that there is something going wrong when the UAC is set to anything which is not Never notify me. However, if I right click on the installer, and select Run as Administrator, the installer works fine.
I then tried to modify the embedded manifest of the installer (methods described below), so that it will always run as admin, but this is not working as I wished. I have obtained the original manifest using the command
mt.exe -inputresource:installer.exe -out:installer.exe.manifest
I, then, opened the extracted manifest using a text editor and changed the line
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
to
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"></requestedExecutionLevel>
I then, tried to apply the resulting manifest, by running the command
mt.exe -manifest installer.exe.manifest -updateresource:installer.exe;#1
but the manifest tool gave me the error
mt.exe : manifest authoring error c1010001: Values of attribute "level" not equal in different manifest snippets.
I also tried changing the command to
mt.exe -manifest installer.exe.manifest -outputresource:installer.exe;#1
but this caused the entire installer to be overwritten by nothing more than the resources (i.e. the actual installer was lost).
I also tried opening the installer executable using Visual Studio (Resource Editor), modified the manifest and saved the file, but this gave the same result as the second mt.exe command I used.
Does anybody know what I am doing wrong, or if I am missing out on something ?
You shouldn't modify the manifest of the resulting Inno setup as Inno does any elevation it needs for the PrivilegesRequired directive.
If you do modify the manifest, or manually do "Run as Administrator" then it will break all the ...AsOriginalUser functionality, most importantly, the postinstall flag.
mt.exe and similar resource editors are also very likely to strip the setup data from the setup file as it's appended to the end of the binary.
I am trying to use my ftp server on netbeans. Is there a way to only put the host and username + password in and then just see all the folders that are on the server?
I already searched for this but I can't seem to find it anywhere.
I am using a mac and netBeans 7.1.1
First, ensure that ant-commons-net.jar is copied to:
C:\Program Files (x86)\NetBeans 6.7.1\java2\modules\ext
Then modify your project's build-impl.xml file, located under the nbproject directory.
Add a new task, such as this, using your ftpsite, username, and pass. Keep that file safe unless you modify it to prompt each time. To execute, run the ftp task by expanding the build.xml from the NB files tree tab.
Code:
====================
FTP SECTION
====================
-->
<target depends="jar" description="Build." name="ftp">
<ftp server="FTPSITEURLHERE" userid="USERIDHERE" password="PASSWORDHERE">
<fileset file="${dist.dir}/${application.title}.jar" />
</ftp>
</target>
<!--
I'm not sure what you mean, you want to create some project from FTP server and don't want to specify exact path? If so you can leave upload directory with just "/" and the same of "initial directory" and it should work