Preserve folder/file secutity and owner information

Sep 11, 2014 at 8:08 AM
Is there a way to preserve security, owner, encryption and filestamps on file/folder copy so the target holds the information of the source?
Coordinator
Sep 11, 2014 at 8:49 AM
The *Info classes (QuickIOFileInfo, QuickIODirectoryInfo) provide methods for all metadata information, for example SetOwner( ), GetOwner( ) and Timestamp values.
The security information are available with GetFileSystemSecurity( ) which returns a QuickIOFileSystemSecurity object wth a lot of properties of the current user's security settings.

Is this what you are looking for?
Sep 11, 2014 at 8:57 AM
Edited Sep 11, 2014 at 8:58 AM
This way i must set the information after creating/copy - is that right?
I hope there is a way like CopyFileExW or xcopy that copies this information also in the copy process.
Maybe setting the information after creation cost not so much time as i think ;-)

Anyway - a great assembly to manage the copy process with long paths and unicode support...
Coordinator
Sep 11, 2014 at 9:12 AM
Edited Sep 11, 2014 at 9:16 AM
QuickIO focuses a high compatibility with the System.IO namespace. It's not easy to combine modern patterns with a high compatibility to the existing interfaces.

If I understand you correctly you want, that the owner of a file can be used/set during the copy. In principle, that would be of course possible.
BUT: it still requires two calls to the API, because there is no interface of Windows (Win32), which would allow this in one call.

First, we have to call "CopyFile" and then call the security methods.
CopyFileExW seems to be (Google search) a custom implementation and is not privided by the OS by default. Cannot find any references in the MSDN.
It does the same: calls CopyFile and then sets the owner.

Thanks for your feedback and ideas :-)

Edit: CopyFileExW seems to be available with Windows 8 and above and is part of the external library "Windows 8 API Sets". But this is still no default interface of Windows / the Win32 and is not compatible with older versions.
Sep 11, 2014 at 9:40 AM
BenjaminAbt wrote:
First, we have to call "CopyFile" and then call the security methods.
CopyFileExW seems to be (Google search) a custom implementation and is not privided by the OS by default. Cannot find any references in the MSDN.
It does the same: calls CopyFile and then sets the owner.
I will try this Copyfile and then set security infos - we need this for a own backup to preserve information of the original file.

btw, CopyfileEx is a kernel32 api and CopyFileExA is the Ansi Alias and CopyFileExW is the Unicode/Wide alternate.

Perhaps a reference to the source object in File/folder copy finished would be helpful - now i try to use a variable, not realy useable in async mode but for me it should work.

Thanx for information
Coordinator
Sep 11, 2014 at 10:30 AM
Edited Sep 11, 2014 at 10:32 AM
I cannot find any references of CopyFileExW in the official documentations. Only CopyFileEx is listed. Also pinvoke does not know 'CopyFileExW'.
The behavior of W and A is known to me; but normally I thought there is also a documentation available.

And CopyFileExW is listed in the Windows 8 API Sets. Do you have a link for older windows versions and CopyFileExW?
CopyFileEx is an async implementation of CopyFile. But does not fit to the normal async/await behavior in .NET. An handler with an external body is required.

You could use async/await with ContinueWith to copy first and then set.
But... In my test environments Win32 CopyFile also copies all file metadata information (flags / attributes) by default. Just NTFS information (owner, rights) will not be copied. That's correct.

Maybe I will write an extension for that behavior.
Marked as answer by BenjaminAbt on 9/12/2014 at 5:10 AM
Sep 12, 2014 at 11:57 AM
Thats right - your copyfile/createdirectory copies all by default. Only missing is encryption, filestamps, owner and rights. In my tests i can set all missing information in completed state, only problem get encryption back - it's encrypted on another machine and saved on a fileserver. It's not so the problem in the moment, good to see the rest of my files looks like a good copy (encryption is missing - target file is decrypted).