I want to move a folder from one drive (e.g. C) to another (say D) without its security descriptor changed. SHFileOperation can move the folder, but new folder on D always inherit the permission from the parent folder. Not to impact other subfolders under the same parent folder, I cannot change the parent folder to stop propogating its permissions to its children.
I have used SetSecurityDescriptorControl with SE_DACL_PROTECTED to disable inherit when creating the folder on C. It seems not to work when move folder cross volumn. I also tried to set security info for the new folder on D, by removing old ACEs. However, those inherited ACEs cannot be removed.
There is a registry ForceCopyAclwithFile (http://thedailyreviewer.com/server/view/copy-folder-w-user-permission-intact-10274759) but I don't want to use it because of its global system impact.
How can I use windows API to move a folder cross disks without permission change? What did I miss here?
Thanks
Leon
You can use BackupRead and BackupWrite to move directories across volumes with NTFS security intact.
BackupRead: http://msdn.microsoft.com/en-us/library/aa362509(VS.85).aspx
BackupWrite: http://msdn.microsoft.com/en-us/library/aa362511(VS.85).aspx
You will need to create the folder at the destination first, then open both folders using CreateFile in order to get handles to them.
Your process will need to obtain the Backup and Restore privileges and you need to pass FILE_FLAG_BACKUP_SEMANTICS into CreateFile.
Related
I am currently opening a folder to restrict access to it, as I don't want to set an ACL on the actual folder.
Is this possible with CreateFile()?
Copy and Pasting works, and that is a problem for me. Drag-and-drop from Windows Explorer does not, however, and has the desired effect.
Any advice here?
I'm merely trying to prevent as much access as possible to the folder with CreateFile() for security reasons, and would prefer to use the CreateFile() API.
I am running a batch file as part of a larger application.
If certain conditions are met, a folder is created and permissions applied to the folder using icacls.
I have permission inheritance disabled on the parent folder, and I want to add to the ACL full permissions for the user "testuser".
I tried the following command...
icacls "V:\debugging\test" /grant testuser:F
The command completes successfully, however when logging in to the folder via CIFS, I do not have full permissions.
I can create files and folders but not modify them.
I cannot even rename a text file during creation, so I end up with a new file called 'New text document' and i have no permission to edit this.
What I need to happen is for the permissions to be applied to "V:\debugging\test" that allow me to read, modify and and write without exception and If possible I need those permissions to be inherited by any child folders that may be created.
Can anyone point me in the right direction?
Someone recently raised a bug against a filter driver I've been working on. They said that I'd made it possible for a limited user to delete Windows files even if they remove the permissions on the file for the user to be able to do that.
I've been looking at it and it's nothing to do with my driver, even a fresh install of Windows allows this. If you:
Logon as a user called "limiteduser" who's a non admin.
Create a text file
Edit the security for the file
Remove inherited permissions and remove "limiteduser" from having any rights to the file.
Once you've done this you find that:
You can't changed the contents of the file.
You can't rename/move the file or send it to the recycle bin
However you can:
Delete the file in explorer with shift-delete
Delete the file with cmd.exe (del myfile.txt)
Why is this? Is deleting files always a property of the parent folder? And if so why isn't renaming files?
I know this answer isn't complete at all, but I hope it will be helpful nonetheless.
You didn't mention which version of Windows you are using, but as the ones that use any version of the NTFS file system should behave the same I believe it doesn't matter.
The documentation on "File and Folder Permissions" in Windows 2008 Server states that:
Groups or users that are granted Full Control on a folder can delete any files in that folder, regardless of the permissions protecting the file.
So it would appear that part of the answer to your question:
Why is this? Is deleting files always a property of the parent folder? And if so why isn't renaming files?
would be that deleting is indeed a property of the parent folder - it looks to me that it's the Delete Subfolders and Filesspecial permission that allows you to override the permissions on the file.
Why the "Full Control" permission on the folder won't give rename permission is unclear to me, but my guess is that it's actually only Delete Subfolders and Filesthat has the power to override; to rename a file you would have to have permissions to write too.
I'm guessing that the reason that "Shift-Del" in Explorer and "del" in cmd works and not "Recycle" would be that recycling is a move/change operation.
See this Technet article for reference: How Permissions Work
I put a shortcut to my application in SendTo. Now I can select some files in Explorer and send them to my application. But how can I get the path where the files are? My program is supposed to create a new file in the parent directory that's common to all the received file names.
For example, if I have these files:
C:\one.txt
C:\1\
I select the file one.txt and the directory 1 in Explorer. How can I find out that the starting directory for these files is C:\?
I know I can use ParamStr() to get files' paths, but what then?
I could try to get common directory for all the files passed to my application, but if I select in C:\ directories 1 and 2 and these directories look like this:
C:\1\4\5\one.txt
C:\1\4\two.txt
Then the starting directory is C:\1\4.
Prior to Windows 7, all files selected in Explorer always reside in the same directory, so it's easy to know which directory the user was browsing. It's the same as the directory of any one file. Use ExtractFilePath for that.
As of Windows 7, though, Explorer lets you put directories into groups called libraries. All the files from all the folders are displayed together in a single view. Users can select files from multiple directories and send them all to your program at once. The view doesn't represent any real directory on the disk, so the question asked here is meaningless.
As an alternative, you could decide use the ancestor directory common to all the files sent to your program, but that won't tell you much. For one thing, if the files reside on multiple drives, the common directory will be the empty string. The directory you calculate also might not be writable by the current account, even if the directories of one or more of the selected files are.
It will probably be easier to just use the directory of the first file you receive, or even to display a UI that asks the user what directory to use in the cases you can't determine it automatically. (Maybe you could pre-populate the result with the first directory, so the user doesn't have to do anything but approve your suggestion in the common case.)
I think I will just take all the filenames passed to my program via ParamStr and use this function:
http://delphi.about.com/od/delphichallengesexercises/qt/delphi-extract-base-path-challenge.htm
to find common base path which should be the path where the SendTo was invoked.
The Finder uses some kind of rules to determine if an Item can be moved or will be copied. After dragging an Item, in certain cases Finder shows a drag-copy-cursor. Are these rules in an API available? Checked with Spotlight-Metadata, NSURL and NSFileManager: no result.
Here's what i came up with:
if a Folder contains a ".localized" File: the folder is copied
if a Folder is listed anywhere in a NSSearchPathDirectory
Is my assumption right? or has it to do with NSURLIsSystemImmutableKey or NSURLIsUserImmutableKey which i thought is the "Locked" flag?
Furthermore depending on various other Metadata like write-permissions and locked-flag:
ON SOURCE:
moving a readonly file: move is possible
moving a readonly folder needs login from an admin
moving a locked file creates a copy
moving a locked folder creates a copy
moving a folder with a locked file inside: move is possible
moving a selection with both locked and unlocked items creates a copy
moving a dropbox writeonly folder: move is possible
writeonly files do not exist in Finder
moving a file without any permissions: move is possible (as the move rights depend on the enclosing folder)
moving a folder with a file without any permission: move is possible (as long its a move, for copy it asks for login)
if a Folder contains a ".localized" File: the folder is copied
if a Folder is listed anywhere in a NSSearchPathDirectory (home directory, ...) it is copied
if a folder contains another book: move is possible
ON TARGET:
moving an item into a dropbox creates a copy
moving an item into a locked folder: not possible
moving an item into a read-only folder: asks for login
*) Regarding the Finder: if a file or directory is being dragged from one volume to another, it will (by default) be copied. If the action is being performed on the same volume the file or folder will (by default) be moved. As a side note to file operations on volumes: 'moving' things across different filesystemes behaves differently, again. Normally, moving a file or directory doesn't mean 'copying' and 'deleting' the original afterwards - only their links within the filesystem usually become modified but here and then, it actually behaves exactly like that.
*) Furthermore, take care of the objects permissions: if filesystem permissions to that source file or a directory (and it's content within) doesn't allow write operations to it, it will be copied again.