Is there any way to prevent making changes/deleting files on partition or folder?
I need a solution, to allow workers to download/copy the file into their local folder but to disallow making any changes or deleting the file at the main destination.
A system which we using is Windows, and we currently don't use Windows Server.
Any ideas?
Best regards.
AK.
Modify the permissions on the folder they are downloading from to allow read but not write or modify for the user/pass they are using to access the share. Then they can copy the file to their local machine all they want but can't modify anything on the share folder.
The solution to this problem is software called "Easy File Locker" (freeware software) which one allows add localization which will be blocked from making any changes. To disable protection by application you must enter password and switch off software.
Best regards.
AK.
Related
I have installed a window application on a machine. When i run exe file and try to read value from config file, it gives different results for different users.
What I have identified:
config file is saved in user's folder not in the application folder in program files.
it pickup setting for different users from local folder :
C:\Users\myUser\AppData\Local\VirtualStore\Program Files (x86)\Parentfolder\ApplicationName
It seems to me that the application was designed to INTENTIONALLY use the users AppData folder to store its settings. It's generally a bad idea to mess with how a program was designed to operate.
HOWEVER, if you have the ability to run a different program that can do file syncing between different machines on the network, you can certainly do something like make a single copy of the config file and put it into a folder somewhere on the network - preferably on a file server, then use a file syncing program and set it up to take that one file and copy it out to each users workstation and drop it into that AppData folder.
Then, you would only need to make a change to that one file and the file sync software will see that it was changed, then it will copy the new file out to the users' workstations.
Here is a link to a site that reviews a bunch of different Windows programs that do file synchronization ... there are probably thousands of options out there ... just google around and find something that works for you in your environment.
By the way, if you go this route, I would make sure that any time you change the config file so that it copies out to the user's workstations, that the users shut down the program until the file has been copied to their workstation. It's possible that the software could have open locks on the file or that changing it while the software is running might piss it off ... so it's just good measure to shut the programs down, then sync the file then have them launch the program again.
Is it possible in IIS to block access to any directory in the public web folder, that has a certain name. For example private_cms?
If possible, is there any performance penalty to this? Would it be better to store the files outside of the www folder?
Add your directory to the "request filter" in IIS:
sorry I use Chinese version of windows
Yes, using Windows Explorer remove permissions for the IIS user to read from that folder.
I am creating a WIX installer project. During one managed customized action, I need to create a file (other than the deployed files specified in the components of WIX) in the installation folder, which by default is the Program Files folder. I am experiencing the "Access denied" problem in Windows 7. After some searching, I found out that people say it is not advisable to create files into Program Files folder. Instead, try to create files into for example AppData folder. For example, see this link:
C# Access denied to path in a Windows Application
But my question is, the generated file is crucial to our SW, so it must reside in the installation folder. Isn't it the target of SW installation, I mean, to create file in most of the cases Program Files folder? Does it mean the only files should be added into installation folder, during the installation, are the deployed files (basically the targets of XCopy)?
My file can't be made deploy-able in the WIX, i.e, it can't be made ready before the installation. So what's the proper way or best practice to handle such situation: a file must be generated during the installation, into the installation folder. It is not some log file that I can put somewhere else. I tried to create a Permission element in WIX for the INSTALLADIR, although it seems to be against the rule mentioned in the link, but it still failed. Thanks!
UPDATE:
Based one MichaelUrman's commen, some more information. The generated file is needed after the SW is installed and necessary during normal launch of the SW. And I think it needs to be modified during normal use after the installation. And as I mentioned my a comment to #caveman_dick answer, my CA is actually in commit phase, I don't know whether there is any difference between it and normal deferred CA
Set the custom action to Execute="deferred", that will run the command elevated and should give it the required permissions to create the file.
Since you need to update that file from the main application, and I'm assuming your application does not require elevated privileges, you have three options.
The first is the worst: without a manifest, your executable's attempts to write to the Program Files folder will typically result in it being redirected to the Virtual Store (see File Virtualization). It sounds like this isn't happening in your case, so you can't use it.
The second option is to modify the application to store this in an appropriate location such as the ProgramData folder, or Common Documents, or (if appropriate) a per-user location under LocalAppData. This is typically the best approach, but has the highest development costs.
Finally the third option is to create the file and change its permissions (or in some cases to change the permissions on the folder containing the file), allowing limited users to modify this file. See LockPermissions or MsiLockPermissionsEx for the Windows Installer way to approach this. Change the permissions on as few files or folders, as restricted as possible, to keep the system as safe as possible if you go with this option.
Currently, I'm developing a system which will extract some files from an SFX archive (files that will be used for another app). I want to make the extracted files hidden, so the person which has find the location of the exe couldn't get the files which will be in same directory with the exe. I know i can apply attrib +h to the files but if the user turns on "show hidden and system files" option in Windows, the files will be visible.
Isn't there any method to overcome this? Any suggestion is welcomed.
Thanks.
If you're writing to the disk, a user can find and read your file. There's no way around that, one could monitor what happens when your application is run, find what files it's writing to, or just intercept while it's being written. Consider why you don't want the user to find your files.
Is it because there's sensitive data, or things you'd rather they didn't change? Consider encrypting it, or verifying it's integrity with a checksum or hash.
Guess you could play around with user rights. However, you'd need to ask an administrator right at install then to make it hidden from the given user who is an admin on the PC.
For several of our applications we use an application configuration file. It usually just stores some directory paths and a few universal settings. We usually save it in the application directory (C:/Program Files/MyAppName)
One problem we see is users want to edit this (from the application) while logged in as a user that doesn't have access to write to the directory. Our applications are commonly installed and initially configured as an admin, but mostly used by (several different) limited users.
Is there a good way to make the setting.xml file read/write accessible to all users? Or a good place to put it?
C:\Documents and Settings\All Users\Application Data\<Your App> might be a decent place to consider.
Pass CSIDL_COMMON_APPDATA to SHGetSpecialFolderPath to get the writable, shared root data directory. Given that you can create a directory for your company and application.
Application data folder or moving to registry.
How important is localization? If localization isn't a high priority, you can store the files in %allusersprofile%\Application Data\ - that's the appdata folder accessible to all user accounts, and will work regardless of where things are installed, but only on English operating system installs.
If you want to store a file in the local user's directory and give each user their own, you can use %appdata% - that one will be entirely localized. But, each user will need their own copy, so it won't work if you need a common configuration.
If you need it to both be common to all users, and be 100% localized, you need to do a bit more work. I tried to find something like %allusersappdata%, and while I can find references online to that string, I can't get it to work on my own system. The workaround I found was to pull up %appdata% to find the localized text for the words Application Data, then use that to browse to that subfolder under %allusersprofile% - a bit more complicated, but it's the most bulletproof way I can find to do it. Someone please correct me if there's a direct path you can use to get to that folder.
I would try this previous question.
Which says:
System.Environment.SpecialFolder.LocalApplicationData
If you are using .NET