I have a folder with permissions already set, in that folder I have some files that should all have the same permissions as the parent folder, the only thing is when these files get replaced by the updater the permissions change.
How can I have the updater replace these files's permissions again with the parent folder's?
Deal with acls sometimes could be annoying, be careful and good luck.
Here is a well-explained article http://msdn.microsoft.com/en-us/magazine/cc163885.aspx
And you could see the icacls and cacls commandline tools.
Use with careful and try to backup before.
Related
How to remove all inherited permissions for directory with SubInAcl.exe?
I can do this with icacls by using /inheritance:r
Is there a way to do the same with SubInAcl?
/perm should work here. I'd be very careful with it though. :)
I'm creating an installer with NSIS which will install more than 100 files.
I know that to specify which files you want to install you can use
File /r ..\release\*
Which works very well.
But what should I do to uninstall these files ( Appart from using the Delete command individually for each file that I know that is installed. )
I've taken a look on RMDir which doesn't seem really safe to use. And also here which didn't work.
Thank you for your time
RMDir is safe. It's use of the /r flag that the doc warns about:
Warning: using RMDir /r $INSTDIR in the uninstaller is not safe.
Though it is unlikely, the user might select to install to the Program
Files folder and so this command will wipe out the entire Program
Files folder, including other programs that has nothing to do with the
uninstaller. The user can also put other files but the program's files
and would expect them to get deleted with the program. Solutions are
available for easily uninstalling only files which were installed by
the installer
Given this, I'd think you'd just manually remove any subdirectories, then delete the parent. The only case that I can think of where this wouldn't work is when your application is generating new folders dynamically. And if that's the case, even the uninstall log isn't going to help you there.
It's also perfectly okay to use /r on a subdirectory that you created. The concern is deletion of the top-level install directory, and everything that may have existed in it. If your installer rolls out a folder with additional assets called images, which also contains subdirectories, there's no reason why
RMDir /r $INSTDIR\images`
would be dangerous.
I am trying to save rules and facts to a specific directory in my CLIPS programs.
(save "c:\tmp\rules.clp")
(save-facts "c:\tmp\facts1")
1- But it seems CLIPS disregards the path information. Since my windows username is not the owner of the CLIPS installation directory, the files are saved in a virtual store directory:
C:\Users\USERNAME\AppData\Local\VirtualStore\Program Files (x86)\CLIPS\Bin
2- If I run a system command and include the path, the same thing happens. The path is disregarded and the notepad cannot find the intended file.
(system "notepad c:\tmp\output.txt")
Is there a way to force these commands to save/read from a specific directory?
CLIPS doesn't have the ability to override directory/files permissions set by the operating system. The path to the save/save-facts command is not modified before being passed to the system libraries for opening files (either fopen or fopen_s). I'd suggest changing the directory permissions if the user account you're using doesn't have write privileges.
I think I have found the problem.
The paths should both be included in double quotes and the slashes should be converted into forward slashes.
I have doubt in directory undeletable concept. In Windows operation system, we convert a Undeletable file or folder in to deletable by using the command as "cacls FolderName /e /c /g %username%:f". I used the same command to access the "Undeletable folders" (for example Recovery, Documents and Settings etc.,), which is present in the C: drive. It doesn't work. How they create this kind of folders. If any other ways to do this. Kindly clear me. Thanks in advance.
Those folders have the "list folder/read data" permission set to deny for everyone. Deny takes precedence over allow, so it doesn't matter what permissions you give to a user: the deny setting will overrule it. You have to remove that setting first, which probably means you also have to take ownership first. They're owned by SYSTEM.
We have two users:
user1
user2
They both belong to the group 'admin'.
We have a directory that has been set to 775. The directory's group has been changed to 'admin'. Each user has full access to write into that directory, though when a user writes a new file to the directory, the group permissions of the folder are not persisted to the file that was written.
How should we make it so that files inherit the directory's group permissions?
Clarification: when a new file or directory is written, it uses the users' group as the group of the new file, rather than that of the directory, which makes sense - but how do I not make that happen?
You can propagate group permissions by setting the directory's setgid bit (chmod g+s). This may not be portable across all *nixes and all file systems.
http://en.wikipedia.org/wiki/Setuid#setgid_on_directories
http://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html
If you are using ext3 or ReiserFS, this page about creating a Linux file server may help. Specifically step 7 suggests the following command.
setfacl -d -m g:sales:rw /groups/sales
I think you should look here.
As the site says, "Unix doesn't support the idea of inherited permissions."
However, there is a section on ACLs (Access Control Lists), which I think is what you are looking for. By setting up an ACL, you can have your files inherit the same ACL from the directory, which I think is what you are asking for. setfacl is the shell command that will be what you need to look into.
Hope that helps!